::--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==-=::
:: ..ooO Protecting Memory and Addressing Part One by wyze1 Ooo.. ::
::--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==-=::
:: ::
:: This is the first of a wave of technical articles which I am going to be ::
:: publishing in FK. I am making a conscious decision to get the zine more ::
:: technically orientated and to have some serious articles for the ::
:: intermediate hacker. ::
:: ::
:: I toyed with the idea of writing an article on Buffer Overflow but after ::
:: having seen this in Phrack, b4b0 and THC Magazine, decided that the idea ::
:: was tired out by now, and by now (hopefully) everyone knows what it is. ::
:: And so, I decided to look into an area less commonly exploited and less ::
:: well-known, memory protection. In this issue I will be covering some ::
:: fairly primitive methods of memory protection and will move on to more ::
:: commonly used systems in Part Two. It is intended to be simple, concise ::
:: and to explain exactly what memory protection is from the ground up. ::
:: ::
:: In multiuser environments (Like Windows NT and UNIX), it is important ::
:: that the memory assigned to one user cannot be accessed in any way by ::
:: another user -- not only for security reasons, but also obviously so ::
:: that if one user's program crashes, the whole system won't go down. Lets ::
:: start by looking at the most basic form of memory protection - protecting::
:: only the Operating System itself in a singleuser environment. This uses ::
:: the Fence Register method. ::
:: ::
:: ____________________ ::
:: | | The Memory ::
:: | Operating System | ::
:: | | ::
:: |--------------------| ::
:: ,- | | ::
:: | | User Program | ::
:: | | Space | ::
:: Addressing Range ---| | | ::
:: | | | ::
:: `- | | ::
:: -------------------- ::
:: ::
:: This is achieved by using a Hardware register called a Fence Register. ::
:: The Fence Register is a lower level memory address that indicates that ::
:: nothing above this should be modified. We would then say that the ::
:: Relocation Factor for this example is the amount of memory blocks a ::
:: program written as if it would be resident at the beginning of the RAM ::
:: would have to move down so as not to interfere with the Operating System.::
:: ::
:: Now, in a multiuser environment we don't want our users to be able to ::
:: cause any trouble for eachother whatsoever and we can't achieve that ::
:: with just our one Fence Register. This is where we bring in Bounds ::
:: Registers. Like how Fence Registers are lower level memory addresses, ::
:: Bounds Registers are higher level memory addresses, and show that all ::
:: memory below it belongs to them. (Until it hits another Bounds Register).::
:: So an example would look something like... ::
:: ::
:: ____________________ ::
:: | | ::
:: | Operating System | ::
:: | | ::
:: Base Register --->> |--------------------| ::
:: | | -, ::
:: | Bobs Program Space | | ::
:: | | | ::
:: Bounds Register --->> |------------------- | |-- User Program Space ::
:: | | | ::
:: | Sods Program Space | | ::
:: | | -' ::
:: -------------------- ::
:: ::
:: However there is still a big problem with this form of memory protection.::
:: Because there is no definition between executable and data areas, and ::
:: because each user has full control over memory in their assigned piece ::
:: of memory, they can write over things and cause crashes and different ::
:: things happening in the execution of their programs. Sure, its only ::
:: their programs, but what if this was a SUID program? ;) ::
:: ::
:: So, what we may want to do, is seperate the users data from their ::
:: program space to avoid security threats like the one mentioned above. So ::
:: our memory will look something like this... ::
:: ::
:: ____________________ ::
:: | | ::
:: | Operating System | ::
:: | | ::
:: Base Register --->> |--------------------| ::
:: | Bobs Data Space | -, ::
:: Bounds Register --->> |--------------------| | ::
:: | Bobs Program Space | | ::
:: Bounds Register --->> |------------------- | |-- User Memory ::
:: | Sods Data Space | | ::
:: Bounds Register --->> |--------------------| | ::
:: | Sods Program Space | -' ::
:: -------------------- ::
:: ::
:: Needless to say, this type of memory protection will not work if we want ::
:: a truly secure Operating System. And that is where Tagged Architecture ::
:: comes in, another alternate method of memory protection. This sytem is ::
:: just really the idea of having a few bits after every Memory location ::
:: that cannot be modified containing flags such as R, W & X, to represent ::
:: what the user may and may not do with this piece of memory, for example ::
:: R - Read, W - Write, X - Execute - like in UNIX. ::
:: ::
:: This system is used on the Burroughs B6500-7500 systems and the IBM ::
:: System/38 also uses a similar method. In next issue I will discuss other ::
:: memory management techniques, including Paging, Segmentation, And a ::
:: hybrid of the two. Please let me know what you think of this article, ::
:: it is my vision of the type of articles which will be in future issues ::
:: of Forbidden Knowledge. ::
:: ::
::--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==-=::
TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2024 AOH
