LWN: Comments on "Memory protection keys"

Memory protection keys

sfink — Mon, 16 Apr 2018 21:06:06 +0000

Ooh, so in 2015 there was some serious work on something that would be extremely valuable for Spectre mitigation!

This seems extremely useful for partitioning untrusted code in a shared process, eg a web browser that doesn't want to take the process-per-domain hit. And for isolating components like the GC and JIT. It's not a complete protection from malicious attack, of course, since if you have somewhat-controlled execution of code within one partition, you may be able to change the key register, but it seems like a pretty good additional barrier to preventing that access in the first place.

I would love to be able to efficiently ensure that no stray writes corrupt GC bookkeeping data. Any memory corruption anywhere tends to crash in the GC because it scans through and chases pointers with lots and lots of memory. This would make it so the mutator would crash immediately at the right place, making errors far far more obvious and likely to be fixed at the root.

Memory protection keys

eSyr — Sat, 12 Nov 2016 17:13:55 +0000

arm, maybe?

Memory protection keys

bgoglin — Mon, 15 Jun 2015 08:55:13 +0000

What does prevent malicious code from enabling access to all 16 regions in their own thread register before trying to access critical data?

Memory protection keys

spender — Mon, 08 Jun 2015 11:34:02 +0000

Some important differences though: DACR cannot be modified by userland without entering the kernel, while protection keys can. AFAIK it's also not possible to implement execute-only pages using domains as no access means no access, whereas protection keys apply to data access only, not instruction fetches. Domains affect the kernel as well while this only affects userland (currently). Domains permit granting permissions greater than that specified by the page tables, while protection keys can only give out a subset of existing permissions (due to the userland-only design).

-Brad

Memory protection keys

marcan — Mon, 08 Jun 2015 09:00:43 +0000

ARM has had this in their MMU for ages, certainly at least since ARM9/ARMv5 (it's called Domain Access Control). The implementation is almost identical: 4 bits in the page table entry select a domain, and a 32-bit Domain Access Control Register has two bits for each of 16 domains to control access.

Except instead of "write disable" and "read disable" bits, there is an extra level of indirection, where the bits choose "no access", "client access", or "manager access". "manager" is R/W, and "client access" can be configured per memory section (1MB virtual address space block) as various combinations of no access, read-only, and read-write for user and supervisor access levels.

Memory protection keys

anton — Thu, 21 May 2015 17:19:36 +0000

One application use that may benefit from cheap changing of protections is garbage collection. There are schemes where you want to catch it if additional pointers from old to new memory are written. If such writes into old memory are rare, catching that with memory protection is more efficient than software checking of writes. I am not sure if the keys described in the article are really useful for that, it has been some time since I read garbage collection papers.

Another application use may be hardening JIT compiler-generated code against vulnerabilities. Last year I heard a presentation where the JIT compiler was put in a separate process to get different protections for the JIT compiler than for the execution. The protection keys may be an easier way to get the same protection.

Memory protection keys

mathstuf — Tue, 19 May 2015 17:32:32 +0000

> At least x86, s390, powerpc and ia64 have some form of protection keys. x86 was the outlier for *not* having it.

Typo? Which side is x86 supposed to be on and what did you intend?

Memory protection keys

hansendc — Thu, 14 May 2015 18:14:09 +0000

Yes, the concept is not a new one in hardware. At least x86, s390, powerpc and ia64 have some form of protection keys. x86 was the outlier for *not* having it.

However, there is currently no general support for these features on any of these architectures in Linux. These patches are the first proposal I know of to use this hardware in Linux in any substantive way.

Memory protection keys

meyert — Thu, 14 May 2015 10:23:41 +0000

Of course, somebody from IBM did also point it out in the belonging thread: https://lkml.org/lkml/2015/5/7/849

Memory protection keys

meyert — Thu, 14 May 2015 10:14:29 +0000

Yes, this was also my first idea! This sounds very similar to s390 storage key protection :-)

Memory protection keys

cotte — Thu, 14 May 2015 09:13:51 +0000

This is hardly new technology, as key protection is a feature of the mainframe architecture from S/360 in 1964: http://en.wikipedia.org/wiki/IBM_System/360#Architectural...