On 05/02/2018 02:23 PM, Andy Lutomirski wrote: >> The kernel could do *something*, probably along the membarrier system >> call. I mean, I could implement a reasonable close approximation in >> userspace, via the setxid mechanism in glibc (but I really don't want to). > > I beg to differ. > > Thread A: > old = RDPKRU(); > WRPKRU(old & ~3); > ... > WRPKRU(old); > > Thread B: > pkey_alloc(). > > If pkey_alloc() happens while thread A is in the ... part, you lose. It > makes no difference what the kernel does. The problem is that the WRPKRU > instruction itself is designed incorrectly. Yes, *if* we define pkey_alloc() to be implicitly changing other threads' PKRU value. Let's say we go to the hardware guys and ask for a new instruction to fix this. We're going to have to make a pretty good case that this is either impossible or really hard to do in software. Surely we have the locking to tell another thread that we want its PKRU value to change without actively going out and having the kernel poke a new value in. -- To unsubscribe from this list: send the line "unsubscribe linux-x86_64" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
