Memory segmentation in modern operating systems

Question

In studying operating systems (primarily with Linux as reference), there are a few points that I don't find well explained in the material that I have studied.

Programs loaded into memory are often described as being divided into segments of text, data, stack etc., even in the context of operating systems like Linux where virtual memory is based purely on paging. Is it the case that it is just the program, and not the memory itself that is referred to as segmented? If so, I find the terminology confusing.

I saw that malloc can be implemented in Linux using the call 'sbrk' that increases the size of the data segment. Again, is this 'data segment' just a region of memory that is used for data by convention and not a 'real' segment? (Extra question: 'sbrk' does not seem to be able to decrease the size of the 'segment'. Does this mean that a process can never release memory to the OS other than quitting?)

Also I am interested in knowing why modern operating systems seems not to be using (paged) segmentation. Wouldn't it prevent certain kinds of attacks to have the code residing in it's own protected segment, thereby increasing security? On the other hand, would this make e.g. JIT compilation impossible/difficult?

Besides "yes"/"no" answers to the questions above, I am interested in any insightful elaboration on the subject.

Sauerbraten

There's also brk, which can set the program break to a lower value. And the segments are partitioned into pages, and each page can indeed be read-only or no-execute, and the text segment and ro-data segment will usually be set thus. – Overstuff

Answer 1

The segment in "data segment" has nothing to do with hardware segmentation, which is a feature of little relevance to modern operating systems (i.e. redundant with respect to paging) which rely on paging to implement virtual memory. Segments also have severe drawbacks compared to paging (e.g. memory contiguous in a segment must be physically contiguous) without any benefit. By "segment" for user-space programs, one literally means a contiguous section of the virtual space of the process.

Many architectures do not have segmentation anymore. On x86, segmentation is just an historical payload and is set up to have a code and data segment that covers the entire address space because segmentation cannot be bypassed.

Your question about freeing memory obtained through sbrk is answered here: How do I free memory obtained by sbrk()?

Usance

Thank you for your answer. Is there no way we could benefit from paged segmentation? It seems to me that having the segments in actual segments with their own address space would simplify memory management and eliminate the possibility of the stack and data segment reaching each other. The segment handling could be handled by the compiler/linker. At any rate, I think that the use of the word "segment" in data segment etc. is just asking for confusion. I guess I should add some disambiguation notes to some wikipedia pages :) – Sauerbraten

@Usance I think you got that mixed up. x86 segments are defined in linear (i.e. virtual) address space, which means paging comes after segmentation. This is stated clearly in section 3.1 of the Intel® 64 and IA-32 Architectures Developer's Manual: Vol. 3A. – Xl

reima: you are right - thanks for pointing it out. Removing these comments. – Usance

Answer 2

Segmentation is actually an issue of the operating system design not on the architecture. In the flat model there is only one segment address, that is the values of CS, DS, ... are fixed by the operating system and programs addresses are maximum 4GB offsets (for 32 bit CPU). I don't know if there are such modern operating systems but it is possible to have not only 4GB address space but 64TB (2^46) address space 16 bits for segment registers + 32 bits offset.

Thusly