Re: Segments

On Mon, 6 Jan 2025 15:05:02 +0000, Terje Mathisen wrote:
 

Anton Ertl wrote:

George Neuner <gneuner2@comcast.net> writes:

The bad taste of segments is from exposure to Intel's half-assed
implementation which exposed the segment selector as part of the
address.
>
Segments /should/ have been implemented similar to the way paging is
done: the program using flat 32-bit addresses and the MMU (SMU?)
consulting some kind of segment "database" [using the term loosely].

>
What benefits do you expect from segments?  One benefit usually
mentioned is security, in particular, protection against out-of-bounds
accesses (e.g., buffer overflow exploits).

>
The best idea I have seen to help detect out of bounds accesses, is to
round all requested memory blocks up to the next 4K boundary and mark
the next page as unavailable, then return a skewed pointer back, so that
the end of the requested region coincides with the end of the (last)
allocated page.
               This does require at least 8kB for every allocation, but
I guess they can all share a single trapping segment?

 You allocate no more actual memory, but you do consume an additional
virtual address PTE on those pages marked no-access. If, later, you
expand that allocated area, you can THEN allocate a page and update
the PTE.
 

(This idea does not help locate negative buffer overruns (underruns?)
but they seem to be much less common?)

 Use an unallocated page prior to the buffer, too.