|
----- Original Message -----
Sent: Tuesday, October 10, 2000 10:06
PM
Subject: Program Objects
Does anyone know exactly how programs are write protected in
memory? Leif has a program (part of chapter 15 in his book) that changes
parts of a program object programmatically. However, if I try to change
other parts (such as the state byte) I get the old domain violation
error. I'm running at seclvl 40 if that makes a difference.
BTW, for those of you who have not bought Leif's eBook I
would highly recommend it!!! I applaud him for doing such a great job on
it and finally filling in some of the gaps for many of us. Thanks
Leif. It's available at http://iseries400.org/ I am in
no way affiliated with Leif other than I bought his book and he has been very
gracious in answering questions.
====> Matt, you are jumping ahead to fast. The following
is from chapter 15 (to appear shortly):
The WRITABLE-HDR-ADDR advertises that it points to a
writable portion of the program object. What is going on here? The
major reason for the AS/400’s stability is not the strength of its design or
the quality of its implementation, but very simply that all executable objects
are write-protected. Not even a system-state program can alter the code or
constants of any other programs directly in memory (setting aside for now the
fact that SST and DST can). To understand the issues around this we need to
look at how virtual memory (or memory paging) works on the AS/400. The central
concept is that of Virtual Effective Address
Translation.
Effective Address Translation
The high-order 12 bits (3 hex digits) determine if the 64-bit
effective address is an address to be translated, an E=R (Effective = Real)
address, or an E=DS (Effective = Direct-Store) address. If the high-order 3
hex digits of the effective address are 800, the address is a ‘real’ address.
Part of the address space is set aside for these E=R addresses to match the
real address range of the machine (which is 52 bits in the current
implementation of the PowerPC).
When an E=R address is detected by the hardware, it checks
the privilege level bit in the Machine State Register (bit 49) to see whether
the process that generated this address can execute privileged instructions
(i.e. runs in supervisor mode). If so, the low-order 52 bits of the
address are passed directly to memory as a real address. The address
x‘8000000000 003000’ is thus the real address x‘3000’.
Another range of addresses is used to access to I/O space.
The PowerPC uses memory-mapped I/O, where any load or store instruction can be
used to pass control to I/O devices using this space. If the high-order 3 hex
digits of the effective address are 801, the address in an E=DS address. As
for the E=R address, supervisor mode is required to access this address
space.
Finally, if the high-order 3 hex digits are neither 800 nor
801, the address is a virtual address to be translated into a real address
using the so-called page table. We’ll not at this point delve into the
intricacies of how the translation is done. Suffice it to say that a hashing
function maps the 52 high-order bits of the address to a page table entry
group (PTEG). Each PTEG contains eight page table entries (PTEs) which are
then searched for the address we want. A PTE points to a 4K page in memory and
the low-order 12 bits of the effective address is then used as an offset into
the page. This is an important point: the granularity of the paging mechanism
is 4K = 4,096 bytes.
Page Protection Bits
Each PTE is 16 bytes long containing page numbers and various
control bits. In particular, the low-order 2 bits are used page protection
bits (PP bits). The memory-protection mechanism in the AS/400 provides
protection on a page-size block. The Machine State Register bit 56 (Processor
Sate bit, PS) together with the PP bits determine access to the page as
follows:
|
PP |
MSR(PS) = 0, system |
MSR(PS) = 1, user |
Usage |
|
00 |
Read/Write |
No access |
MI system domain spaces |
|
01 |
Read/Write |
Read only |
MI process control spaces;
Program object associated spaces |
|
10 |
Read/Write |
Read/Write |
User domain spaces |
|
11 |
Read only |
Read only |
Generated and SLIC code and
constants |
You can see that all code and constants within the code are
"Read only" regardless of the program state. It is also clear that the
protection is on a 4K pages only, so if any bytes within the page are
protected, so are all bytes within the page, and conversely, if any bytes
within the page are not protected, so are all bytes within the page. This
leads us back to the WRITABLE-HDR-ADDR.
Writable Program Header
The WRITABLE-HDR-ADDR points to somewhere within the
first 4K of the program object (at x‘0100’ in fact), meaning that although the
program object is ordinarily ‘Read only’ or write-protected, the first 4K
bytes are not protected. The main reason for this is lock management. You want
to have a very direct way as placing a lock on an object. A lock count is
stored in the Writable Program Header. The header has PP bits of 01 so that
system programs can change it, but user programs
cannot.
|
midrange.com
