• Subject: Re: Program Objects
  • From: "Leif Svalgaard" <leif@xxxxxxxx>
  • Date: Tue, 10 Oct 2000 22:13:52 -0500

----- 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:


MSR(PS) = 0, system

MSR(PS) = 1, user




No access

MI system domain spaces



Read only

MI process control spaces;

Program object associated spaces




User domain spaces


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.

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2022 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.