Re: [PATCH] pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On 05/02/2018 11: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);

Thread B:

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.

Even that is solvable, as long as the architecture as exact traps: You can look at the program counter and patch up the registers accordingly if the code is in the critical section. Of course, this would need centralizing PKRU updates in a vDSO or a single (glibc) library function. Certainly not nice and even horrible enough not to do it, but I don't think it's actually impossible.

Didn't we discuss this before?

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

[Index of Archives]     [Linux ia64]     [Linux Kernel]     [DCCP]     [Linux ARM]     [Yosemite News]     [Linux SCSI]     [Linux Hams]
  Powered by Linux