4 ms·

> its purpose is to request a region of memory that is mapped only for the calling process and inaccessible to anybody else, including the kernel. Easy fix: at

> its purpose is to request a region of memory that is mapped only for the calling process and inaccessible to anybody else, including the kernel. Easy fix: at the next context switch, the kernel overwrites the code of the process with its own code that copies the contents of the "secret" memory to somewhere the kernel can read it, and then executes its own code. I guess I don't understand the threat model in which having data protected from the kernel is helpful. If the idea is that the kernel is malicious, then it's not going to work in the first place (e.g. the kernel could just fail to honour the MAP_EXCLUSIVE flag in the first place). If the idea is that the kernel is initially trustworthy but gets compromised some time after the memory is made "exclusive", then it can execute its own arbitrary code in that process's context and get the contents that way.

hvidgaard 7y ago
The threat model is basically another process compromising the kernel. Think security systems in shared environments. It's supposed to be hardware based. If process A requests memory with MAP_EXCLUSIVE, and it verifies that it got it that way, the hardware is supposed to make sure the memory is only available to that particular process. No amount of context switching is allowing the kernel to read it, nor could should it be able to modify the running code in a process if it's properly hardened (e.g. put the code to run in the protected area). It pose some interesting challenges, but it seems quite possible
- PeterisP 7y ago
  This seems weird - the hardware has no notion of processes, that's a construct implemented by the kernel. It can enforce a separation of privileges between kernel and non-kernel, but that's about it. Hardware gets a flag that says "am I in privileged mode now?" and it does not (and fundamentally can not) know to whether the currently running code belongs to process A or something else, or to whom a particular memory region belongs - as far as hardware is concerned, there's no "whom" at all, that's an abstract construct arbitrarily introduced and maintained by the OS.
  - Dylan16807 7y ago
    That's how it works right now on x86. There's no reason hardware can't be given a notion of processes, and used to set boundaries between each other and the kernel. It's not an untested idea.
  - hvidgaard 7y ago
    While the current crop of mainstream CPUs does not support anything like it, the idea is old. Basically the CPU need to have hardware support for a PCB and be solely responsible for context switching, and the already complex MMU needs to be context aware. I'm pretty sure we've seen specialized CPUs in the past that did exactly that.
jwilk 7y ago
I guess it's a protection against kernel memory disclosure bugs.
MaulingMonkey 7y ago
I think the threat model is a buggy kernel - or a kernel insuffiently hardened against buggy processors with speculative execution side channels - with a malicious process. E.g. if syscall S reads kernel memory without properly checking pointers/offsets (maybe GCC optimized them out), then process A can possibly use that to steal process B's secrets. Or maybe the kernel does check the pointers/offsets, but isn't hardened against yet another speculative execution side channel attack your processor is vulnerable to, so leaks some information via timing information. MAP_EXCLUSIVE breaks that exploit, and to unbreak it you need both syscall S and another buggy syscall (or maybe another row hammer attack) - to write kernel memory - and to successfully leverage that into tricking the kernel into remapping process B's pages. No panacea, but I could see it rasing the bar in exploit difficulty as part of a defense in depth strategy.
- mike_hock 7y ago
  It does seem weird to protect user space memory from the kernel but not the memory of kernel subsystems from other kernel subsystems. But at that point we're at a microkernel design that needs context switches between kernel processes... Good, I'd welcome that. This feature just implements a level of security that the whole kernel needs to catch up to before it makes sense.
dzdt 7y ago
I think you are getting at the same question Alan Cox had. As quoted in the article: IMHO the question is what is the actual semantic here. What are you asking for ? Does it mean "at any cost", what does it guarantee (100% or statistically), what level of guarantee is acceptable, what level is -EOPNOTSUPP or similar ? I think different semantics as Cox mentions would correspond to different threat models. With the right hardware support, it could mitigate against a kernel that falls under an attacker's complete control after the memory has been allocated. With less support it could mitigate against an attacker who can exploit read accesses at kernel privilege. But the details seem a bit open still...
cm2187 7y ago
I am thinking windows, so perhaps things are a bit different in linux, but most of your drivers run in kernel mode, that's a lot of code contributed by a lot of different companies that is fully trusted with all you can eat access.
pilif 7y ago
It's about providing some defense against buggy and/or untrusted kernel driver modules maintained out-of-tree. An exploit in your closed-source nvidia graphics driver should not get access to your private keys.
- jstanley 7y ago
  But it still will do if the nvidia graphics driver can override the code of your process, even if the nvidia graphics driver can't directly read the protected area of memory.
drewg123 7y ago
It could also just access the physical memory via the direct map (the 1:1 mapping of physical to kernel virtual address space). In fact, this is kind of easier now, since you're guaranteed to find all the interesting stuff in physical memory since MAP_EXCLUSIVE memory cannot be paged out.
- bzbarsky 7y ago
  This is why the article says MAP_EXCLUSIVE would exclude the relevant pages from the direct map.
  - drewg123 7y ago
    Ugh, I missed that. But there is still nothing preventing a malicious (nvidia) driver from re-adding the pages back. In fact, since they are missing from the direct map, it points anything malicious right at the interesting physical addresses..

hvidgaard 7y ago

The threat model is basically another process compromising the kernel. Think security systems in shared environments. It's supposed to be hardware based. If process A requests memory with MAP_EXCLUSIVE, and it verifies that it got it that way, the hardware is supposed to make sure the memory is only available to that particular process. No amount of context switching is allowing the kernel to read it, nor could should it be able to modify the running code in a process if it's properly hardened (e.g. put the code to run in the protected area). It pose some interesting challenges, but it seems quite possible

PeterisP 7y ago
This seems weird - the hardware has no notion of processes, that's a construct implemented by the kernel. It can enforce a separation of privileges between kernel and non-kernel, but that's about it. Hardware gets a flag that says "am I in privileged mode now?" and it does not (and fundamentally can not) know to whether the currently running code belongs to process A or something else, or to whom a particular memory region belongs - as far as hardware is concerned, there's no "whom" at all, that's an abstract construct arbitrarily introduced and maintained by the OS.
- Dylan16807 7y ago
  That's how it works right now on x86. There's no reason hardware can't be given a notion of processes, and used to set boundaries between each other and the kernel. It's not an untested idea.
- hvidgaard 7y ago
  While the current crop of mainstream CPUs does not support anything like it, the idea is old. Basically the CPU need to have hardware support for a PCB and be solely responsible for context switching, and the already complex MMU needs to be context aware. I'm pretty sure we've seen specialized CPUs in the past that did exactly that.

jwilk 7y ago

I guess it's a protection against kernel memory disclosure bugs.

MaulingMonkey 7y ago

I think the threat model is a buggy kernel - or a kernel insuffiently hardened against buggy processors with speculative execution side channels - with a malicious process. E.g. if syscall S reads kernel memory without properly checking pointers/offsets (maybe GCC optimized them out), then process A can possibly use that to steal process B's secrets. Or maybe the kernel does check the pointers/offsets, but isn't hardened against yet another speculative execution side channel attack your processor is vulnerable to, so leaks some information via timing information. MAP_EXCLUSIVE breaks that exploit, and to unbreak it you need both syscall S and another buggy syscall (or maybe another row hammer attack) - to write kernel memory - and to successfully leverage that into tricking the kernel into remapping process B's pages. No panacea, but I could see it rasing the bar in exploit difficulty as part of a defense in depth strategy.

mike_hock 7y ago
It does seem weird to protect user space memory from the kernel but not the memory of kernel subsystems from other kernel subsystems. But at that point we're at a microkernel design that needs context switches between kernel processes... Good, I'd welcome that. This feature just implements a level of security that the whole kernel needs to catch up to before it makes sense.

dzdt 7y ago

I think you are getting at the same question Alan Cox had. As quoted in the article: IMHO the question is what is the actual semantic here. What are you asking for ? Does it mean "at any cost", what does it guarantee (100% or statistically), what level of guarantee is acceptable, what level is -EOPNOTSUPP or similar ? I think different semantics as Cox mentions would correspond to different threat models. With the right hardware support, it could mitigate against a kernel that falls under an attacker's complete control after the memory has been allocated. With less support it could mitigate against an attacker who can exploit read accesses at kernel privilege. But the details seem a bit open still...

cm2187 7y ago

I am thinking windows, so perhaps things are a bit different in linux, but most of your drivers run in kernel mode, that's a lot of code contributed by a lot of different companies that is fully trusted with all you can eat access.

pilif 7y ago

It's about providing some defense against buggy and/or untrusted kernel driver modules maintained out-of-tree. An exploit in your closed-source nvidia graphics driver should not get access to your private keys.

jstanley 7y ago
But it still will do if the nvidia graphics driver can override the code of your process, even if the nvidia graphics driver can't directly read the protected area of memory.

drewg123 7y ago

It could also just access the physical memory via the direct map (the 1:1 mapping of physical to kernel virtual address space). In fact, this is kind of easier now, since you're guaranteed to find all the interesting stuff in physical memory since MAP_EXCLUSIVE memory cannot be paged out.

bzbarsky 7y ago
This is why the article says MAP_EXCLUSIVE would exclude the relevant pages from the direct map.
- drewg123 7y ago
  Ugh, I missed that. But there is still nothing preventing a malicious (nvidia) driver from re-adding the pages back. In fact, since they are missing from the direct map, it points anything malicious right at the interesting physical addresses..