Re: [MI400] using _pcoptr proc. was: Attention Users of *SYSTEM State

[Dave McKenzie <davemck@xxxxxxxxxxxxx>]

Walden H. Leverich wrote:
> Steve said:
> > Actually, I still dont understand the system state thing.  
>
> Steve, I think the state/domain rules apply when you're using MI to
> manipulate things. The opcodes check that you've got the appropriate
> "rights" and either allow the operation or throw an exception. In your
> case you're below the MI, I don't think you'll be constrained by those
> restrictions. 

No, actually, hardware storage protection is a function of the PowerPC
processor (thus "hardware") and exists at all levels.  There are two
protection bits for each 4K page of memory that control what access
(read or write) is allowed in user/system state and problem/privileged
state.

You can use SST to see the protection bits for a given address.
Select (this is on V5R3):

 1 Display/Alter storage
 2 Licensed Internal Code (LIC) data
14 Advanced analysis

select ADDRESSINFO
enter the address like 0db0a9f493000000
F10 to page right

The codes for the protection bits are in the Pp column; top for software
page table, bottom for hardware page table (normally the same)

You can see what the codes mean by entering -s instead of an address.

I looked at the address of a *usrspc, and the codes were 2, meaning
reads and writes were allowed in all states.  That's because protection
is at the 4K page level, and the usable part of a *usrspc starts at
offset x200 (which is in the first page of the *usrspc, right after the
header Steve modified).  Since user state pgms are allowed to write to
*usrspc's, the first page has to be unprotected.  In some future
release, IBM could change the usable part to start at x1000 (the second
page) and protect the first page, thus foiling Steve's exploit.

I also looked at the address of a *file object, which is also a space
(of type 1901).  The first page was coded 0 (read/write only in system
state).

> Gene said:
> > ... Depends on an object's hardware storage protection bits ...
>
> I thought we decided in the LQ and SELRI thread that the hardware
> protection bits were no longer applicable, the protection is done by the
> translator emiting the appropriate Power opcodes. Since Steve emits his
> own opcodes he's free to ignore the protection, no?
>
> -walden

That was about tag bits, which are different from storage protection
bits.  Storage protection is enforced by the hardware.

--Dave