On Mon, Jul 11, 2016 at 12:35 AM, Ingo Molnar <mi...@kernel.org> wrote: > > * Andy Lutomirski <l...@amacapital.net> wrote: > >> On Jul 9, 2016 1:37 AM, "Ingo Molnar" <mi...@kernel.org> wrote: >> > >> > >> > * Dave Hansen <d...@sr71.net> wrote: >> > >> > > On 07/08/2016 12:18 AM, Ingo Molnar wrote: >> > > >> > > > So the question is, what is user-space going to do? Do any glibc >> > > > patches >> > > > exist? How are the user-space library side APIs going to look like? >> > > >> > > My goal at the moment is to get folks enabled to the point that they can >> > > start >> > > modifying apps to use pkeys without having to patch their kernels. >> > > I don't have confidence that we can design good high-level userspace >> > > interfaces >> > > without seeing some real apps try to use the low-level ones and seeing >> > > how they >> > > struggle. >> > > >> > > I had some glibc code to do the pkey alloc/free operations, but those >> > > aren't >> > > necessary if we're doing it in the kernel. Other than getting the >> > > syscall >> > > wrappers in place, I don't have any immediate plans to do anything in >> > > glibc. >> > > >> > > Was there something you were expecting to see? >> > >> > Yeah, so (as you probably guessed!) I'm starting to have second thoughts >> > about the >> > complexity of the alloc/free/set/get interface I suggested, and Mel's >> > review >> > certainly strengthened that feeling. >> > >> > I have two worries: >> > >> > 1) >> > >> > A technical worry I have is that the 'pkey allocation interface' does not >> > seem to >> > be taking the per thread property of pkeys into account - while that >> > property >> > would be useful for apps. That is a limitation that seems unjustified. >> > >> > The reason for this is that we are storing the key allocation bitmap in >> > struct_mm, >> > in mm->context.pkey_allocation_map - while we should be storing it in >> > task_struct >> > or thread_info. >> >> Huh? Doesn't this have to be per mm? Sure, PKRU is per thread, but >> the page tables are shared. > > But the keys are not shared, and they carry meaningful per thread information. > > mprotect_pkey()'s effects are per MM, but the system calls related to > managing the > keys (alloc/free/get/set) are fundamentally per CPU. > > Here's an example of how this could matter to applications: > > - 'writer thread' gets a RW- key into index 1 to a specific data area > - a pool of 'reader threads' may get the same pkey index 1 R-- to read the > data > area.
Sure, but this means you allocate index 1 once and then use it in both threads. If you allocate separately in each thread, nothing guarantees you'll get the same index both times, and if you don't then the code doesn't work. > >> There are still two issues that I think we need to address, though: >> >> 1. Signal delivery shouldn't unconditionally clear PKRU. That's what >> the current patches do, and it's unsafe. I'd rather set PKRU to the >> maximally locked down state on signal delivery (except for the >> PROT_EXEC key), although that might cause its own set of problems. > > Right now the historic pattern for signal handlers is that they safely and > transparently stack on top of existing FPU related resources and do a > save/restore > of them. In that sense saving+clearing+restoring the pkeys state would be the > correct approach that follows that pattern. There are two extra > considerations: > > - If we think of pkeys as a temporary register that can be used to > access/unaccess > normally unaccessible memory regions then this makes sense, in fact it's > more > secure: signal handlers cannot accidentally stomp on an encryption key or > on a > database area, unless they intentionally gain access to them. > That how I think I would think of them, but for this to be fully safe, we'd want to lock them down in signal handlers by default, which is what I'm suggesting. --Andy
