This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libc/22396] x86-64: siglongjmp does not restore PKRU register


https://sourceware.org/bugzilla/show_bug.cgi?id=22396

--- Comment #7 from Florian Weimer <fweimer at redhat dot com> ---
(In reply to Dave Hansen from comment #4)
> Back to PK... The manpage
> (http://man7.org/linux/man-pages/man7/pkeys.7.html) could use some
> additional clarity here, but it does mention the signal behavior, and also
> says:
> 
>     The rights of any interrupted context are
>     restored when the signal handler returns.
> 
> We could clarify that we truly mean sys_sigreturn() and that other
> mechanisms don't count as "returning".
> 
> The kernel _could_ detect when someone unblocks signals from inside a signal
> handler, but without doing a sys_sigreturn().  We could theoretically take
> some action there.  Does that do us any good?

Maybe we are approaching this from the wrong angle.  The main problem I see are
pages which are read in many places, but are read-only most of the time.  Here,
the delivery of a signal and a return through siglongjmp would revoke read
access as well (with the kernel defaults).  If we could tell the kernel at
pkey_alloc time that the access rights specified are the initial access rights
for signal handlers (overriding the system default), then the issue would quite
benign because the signal handle restores the access rights to their current
values, which is essentially a NOP.  Only for regions which enhance their
privileges using a temporary PKRU update, this would make a difference, but
they would also have to have a sigsetjmp landing site, so they are obviously
aware of the complexities.

For the larger problem, maybe we should add interface which merge the jmpbuf
context with the signal handler context before returning to the sigsetjmp site.
 This will at least help new programs.

But I think for MPK, the pkey_alloc flag would be sufficient for glibc's own
needs.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]