linux-kernel - Re: Memory protection keys: Signal handlers crash if pkey0 is write-disabled

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <E821837A-22AD-420C-A290-8511344E7EAF@gmail.com>
Date:   Thu, 7 Sep 2023 19:07:52 -0400
From:   Robert Kueffner <r.m.kueffner@...il.com>
To:     Dave Hansen <dave.hansen@...el.com>
Cc:     Kyle Huey <me@...ehuey.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Borislav Petkov <bp@...en8.de>, linux-kernel@...r.kernel.org,
        linux-mm@...ck.org, Robert Kueffner <r.m.kueffner@...il.com>
Subject: Re: Memory protection keys: Signal handlers crash if pkey0 is
 write-disabled

> I assume that *something* is trying to access pkey-0-protected memory.
> Any idea what that is?  Which entity is doing that access and what are
> they accessing?  The page fault tracepoints might come in handy.

If I understand correctly, the kernel (a) pushes the processor state onto the stack and (b) resets PKRU=0x55555554 some time before switching to the signal handler. And may try between (a) and (b) to write pkey-0-protected memory. 

This would be compatible with what I see when my user code causes a FPE, upon which there is a SEGV before the kernel switches to my signal handler. 

If the user code causes SEGV my signal handler actually executes and only fails later when returning from syscall 14 in sigprocmask(), i.e. sigprocmask() => __GI___sigprocmask => __GI___pthread_sigmask => syscall 14

I will look into tracepoints - but that would be diagnostic rather

As a farfetched solution, would there be a way, perhaps via a kernel hook, to reset PKRU before the kernel actually starts processing the signal?