Intel ITANIUM ARCHITECTURE - SOFTWARE DEVELOPERS VOLUME 3 REV 2.3, Manual

Page: 812 / 1898

2:564 Volume 2, Part 2: Memory Management
5.1.2 Protection Keys
The Itanium architecture provides two mechanisms for applying protection to pages.
The first mechanism is the access rights bits associated with each translation. These
bits provide privilege level-granular access to a page. The second mechanism is the
protection keys. Protection keys permit domain-granular access to a page. These are
especially useful for mapping shared code and data segments in a globally shared
region, and for implementing domains in a single address space (SAS) operating
system.
Protection key checking is enabled via the PSR.pk bit. When PSR.pk is 1, instruction,
data, and RSE references go through protection key access checks during the
virtual-to-physical address translation process.
All processors based on the Itanium architecture implement at least 16 protection key
registers (PKRs) in a protection key register cache. The OS is responsible for
maintaining this cache and keeping track of which protection keys are present in the
cache at any given time.
Each protection key register contains the following fields:
• v – valid bit. When 1, this register contains a valid key, and is checked during
address translation whenever protection keys are enabled (PSR.pk is 1).
• wd – write disable. When 1, write permission is denied to translations which match
this protection key, even if the data TLB access rights permit the write.
• rd – read disable. When 1, read permission is denied to translations which match
this protection key, even if the data TLB access rights permit the read.
• xd – execute disable. When 1, execute permission is denied to translations which
match this protection key, even if the instruction TLB access rights give execute
permission.
• key – protection key. An 18- to 24-bit (depending on the processor
implementation) unique key which tags a translation to a particular protection
domain.
When protection key checking is enabled, the protection key tagged to a referenced
translation is checked against all protection keys found in the protection key register
cache. If a match is found, the protection rights specified by that key are applied to the
translation. If the access being performed is allowed by the matching key, the access
succeeds. If the access being performed is not allowed by the matching key (e.g.
instruction fetch to a translation tagged with a key marked ‘xd’), a Protection Key
Permission fault is raised by the processor. The OS may then decide whether to
terminate the offending program or grant it the requested access.
If no match is found, a Protection Key Miss fault is raised by the processor, and the OS
must insert the correct protection key into the PKRs and retry the access.
Protection keys can be used to provide different access rights to shared translations to
each process. For example, assume a shared data page is tagged with a protection key
number of 0xA. Two processes share this data page: one is the producer of the data on
this page, and the other is only a consumer. When the producer process is running, the
OS will insert a valid PKR with the protection key 0xA and the ‘wd’ and ‘rd’ bits cleared,
to allow this process to both read and write this page. When the consumer process is