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);
...
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.

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?

Thanks,
Florian




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux