Visit our newest sister site!
Hundreds of free aircraft flight manuals
Civilian • Historical • Military • Declassified • FREE!


TUCoPS :: General Information :: protmem2.txt

Memory and Addressing Protection Part Two





::--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--::
::        .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-2014 AOH