* Ingo Molnar <mingo@xxxxxxxxxx> wrote: > > * Dave Hansen <dave@xxxxxxxx> wrote: > > > > Another question, related to enumeration as well: I'm wondering whether > > > there's any way for the kernel to allocate a bit or two for its own purposes - > > > such as protecting crypto keys? Or is the facility fundamentally intended for > > > user-space use only? > > > > No, that's not possible with the current setup. > > Ok, then another question, have you considered the following usecase: So, I'm wondering about the following additional usecase: Right now the native x86 PTE format allows two protection related bits for user-space pages: _PAGE_BIT_RW: if 0 the page is read-only, if 1 then it's read-write _PAGE_BIT_NX: if 0 the page is executable, if 1 then it's not executable As discussed previously, pkeys allows 'true execute only (--x)' mappings. Another possibility would be 'true write-only (-w-)' mappings. This too could in theory be introduced 'transparently', via 'pure PROT_WRITE' mappings (i.e. no PROT_READ|PROT_EXEC bits set). Assuming the amount of user-space with implicit 'PROT_WRITE implies PROT_READ' assumptions is not unmanageble for a distro willing to try this. Usage of this would be more limited than of pure PROT_EXEC mappings, but it's a nonzero set: - Write-only log buffers that are normally mmap()-ed from a file. - Write-only write() IO buffers that are only accessed via write(). (kernel-space accesses ignore pkey values.) glibc's buffered IO might possibly make use of this, for write-only fopen()ed files. - Language runtimes could improve their security by eliminating W+X mappings of JIT-ed code, instead they could use two alias mappings: one alias is a true-exec (--x) mapping, the other (separately mapped, separately randomized) mapping is a true write-only (--x) mapping for generated code. In addition to the security advantage, another advantage would be increased robustness: no accidental corruption of IO (or JIT) buffers via read-only codepaths. Another advantage would be that it would utilize pkeys without having to teach applications to use new system calls. Thanks, Ingo -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>