::--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--::
:: .ooO Memory and Addressing Protection Part Two by wyze1 Ooo. ::
::--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--::
:: ::
:: In Part One I covered the use of Fence and Bounds Registers, as well as ::
:: Tagged architecture. In this Issue, I will be covering Segmentation, ::
:: Paging, and sucessfully combining the two schemes. ::
:: ::
:: Segmentation is simply the idea of dividing a program into seperate ::
:: pieces in memory. Each piece has a logical unity, a relationship among ::
:: all of its data or code values and a completely unique name. They are ::
:: also all different sizes. So our program would be divided into pieces ::
:: that look something like this... ::
:: ::
:: ._______________ ::
:: | MAIN | ::
:: |---------------| ::
:: | | ::
:: | SUB_ROUTN_A | ::
:: | | ::
:: |---------------| ::
:: | DATA_SEG_B | ::
:: | | ::
:: `---------------' ::
:: ::
:: The Operating System maintains a table of segment names and their true ::
:: addresses in memory. A Program that is trying to access a piece of its ::
:: data, a code segment, or whatever it's accessing, will look it up not ::
:: as a real memory address, but as a <Name, Offset> pair. Name, of course, ::
:: being the name of the segment, and Offset being how many bytes whatever ::
:: we want is from the beginning of the segment. (Eg. SUB_ROUTN_A, 150). ::
:: For efficiency sake, there is often one address table for each user ::
:: process in execution. ::
:: ::
:: And so, a users program does not know where it *really* is in memory. ::
:: It is impossible for it to change a <Name, Offset> pair into a real ::
:: memory address. There are three advantages of this for the OS... ::
:: ::
:: 1. A Segment can be removed from main memory and stored somewhere else ::
:: if it is not currently in use. ::
:: ::
:: 2. The OS can place any segment in any location, and can move it around ::
:: as it pleases, even after execution, because all it needs to do is ::
:: modify the address table after it has moved the memory. ::
:: ::
:: 3. Every address reference passes through the Operating System, so we ::
:: can check for protection. (Eg. Read Only Segment etc) ::
:: ::
:: Let's look a bit at this last point. Because everything goes through the ::
:: OS, it is easy for us to store values of what users may or may not do to ::
:: specific pieces of memory. One user could be able to access a certain ::
:: segment of another user's memory if deemed necessary, but still not be ::
:: able to touch anything else of theirs. There is a much greater potential ::
:: for versatile protection using this method than any we have looked at ::
:: in Part One. ::
:: ::
:: BUT... This system has a gaping security flaw (which can be fixed with ::
:: a bit of extra work) which you may have seen by now. What happens if our ::
:: segment is 200 bytes long and we give a 400 byte offset? Oops. Quick and ::
:: easy access to other people's memory - Not good. ::
:: ::
:: This system also causes memory fragmentation, because segments are of ::
:: varying sizes and after awhile, unused fragments of space can lead to ::
:: really shit memory utilization. Ugh. That just about kills it for me, ::
:: lets move on to Paging. ::
:: ::
:: Paging is fairly similar to Segmentation, in that each address is still ::
:: a two part object, this time consisting of <Page, Offset>. Programs are ::
:: divided into EQUAL-sized pieces called Pages and memory is divided into ::
:: units of the same size, called Page Frames. So our program, once divided ::
:: will look like this... ::
:: ::
:: ._______________ ::
:: | PAGE 0 | ::
:: |---------------| ::
:: | PAGE 1 | ::
:: |---------------| ::
:: | PAGE 2 | ::
:: |---------------| ::
:: | PAGE 3 | ::
:: `---------------' ::
:: ::
:: Because Pages are the same size, we don't have memory fragmentation ::
:: problems like we have with Segmentation. Also, we don't have to worry ::
:: about users setting huge offsets. For example, lets say we have a page ::
:: size of 1024 bytes. 10 bits are allocated for the offset portion of each ::
:: address. A program cannot generate a offset value larger than 1023 in ::
:: ten bits! ;) ::
:: ::
:: Moving to the the next location after <x, 1023> causes a carry into the ::
:: page portion, thereby moving translation to the next page. During the ::
:: translation, there is a check to make sure that this program has not ::
:: gone over the amount of pages it has been assigned. ::
:: ::
:: BUT... because there is no unity to the items on a page, there is no way ::
:: to flag all values on a page as execute-only or read-only, or whatever ::
:: we are trying to do. We don't have the sharing and restricting ::
:: capabilities segmentation offered us. :( ::
:: ::
:: So, what do we do? We combine the two! The program is divided into ::
:: logical segments, like in Segmentation, and then each segment is broken ::
:: down into pages of equal size. Easy as that! And the flaws of each ::
:: scheme are fixed! This is in fact the exact memory scheme that they used ::
:: in Multics. ::
:: ::
:: <Newbie Note: Multics was an early operating system made by AT&T, Bell ::
:: Labs, and a whole bunch of other really big companies. One programmer ::
:: was developing a space travel game for Multics which he was very ::
:: excited about, but ended up not having a OS to run it on when Multics ::
:: was found to be the slowest, crappest OS on earth. So, he was forced to ::
:: program his OWN OS for his space travel game, and he called it UNIX, a ::
:: pun on the "Multi" of Multics. The rest is history.> ::
:: ::
:: Well, that's all for now. If anyone found this interesting and bugs me ::
:: enough I will continue giving more modern examples of memory protection. ::
:: But until then - Adios! ::
:: ::
:: --=====-- ::
:: * Bambi (sdfg@ndf53-02-p61.gt.saix.net) has joined #hack ::
:: * Bambi was kicked by ugh (Run home - I think some-one shot your mother) ::
:: --=====-- ::
:: ::
::--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--::
TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2024 AOH
