linux-kernel - Re: [RFC PATCH v2 00/15] pkeys-based page table hardening

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] [day] [month] [year] [list]

Message-ID: <83b57cc5-fe6f-483b-b7e3-8d6e356c914f@arm.com>
Date: Mon, 13 Jan 2025 11:10:34 +0100
From: Kevin Brodsky <kevin.brodsky@....com>
To: Dave Hansen <dave.hansen@...el.com>, linux-hardening@...r.kernel.org
Cc: linux-kernel@...r.kernel.org, Andrew Morton <akpm@...ux-foundation.org>,
 Mark Brown <broonie@...nel.org>, Catalin Marinas <catalin.marinas@....com>,
 Dave Hansen <dave.hansen@...ux.intel.com>, Jann Horn <jannh@...gle.com>,
 Jeff Xu <jeffxu@...omium.org>, Joey Gouly <joey.gouly@....com>,
 Kees Cook <kees@...nel.org>, Linus Walleij <linus.walleij@...aro.org>,
 Andy Lutomirski <luto@...nel.org>, Marc Zyngier <maz@...nel.org>,
 Peter Zijlstra <peterz@...radead.org>,
 Pierre Langlois <pierre.langlois@....com>,
 Quentin Perret <qperret@...gle.com>, "Mike Rapoport (IBM)"
 <rppt@...nel.org>, Ryan Roberts <ryan.roberts@....com>,
 Thomas Gleixner <tglx@...utronix.de>, Will Deacon <will@...nel.org>,
 Matthew Wilcox <willy@...radead.org>, Qi Zheng <zhengqi.arch@...edance.com>,
 linux-arm-kernel@...ts.infradead.org, x86@...nel.org
Subject: Re: [RFC PATCH v2 00/15] pkeys-based page table hardening

On 09/01/2025 17:30, Dave Hansen wrote:
> One of the sticker things in the x86 attempt to do the same thing was
> context switching, both between normal tasks and in/out of exceptions
> and interrupts.
>
> The easiest place this manifested for us was code chunk like this:
>
> 	kpkeys_set_level(KPKEYS_LVL_PGTABLES);
> 	// modify page tables here
> 	kpkeys_restore_pkey_reg();
>
> We had to make sure that we didn't get preempted and context switch over
> to some other task that _wasn't_ doing page table manipulation while
> page table writes were allowed.
>
> On x86, we had to basically start context-switching the kernel pkey
> register the same way we do GPRs.
>
> How is SYS_POR_EL0 being context switched?

I think this is pretty much the same situation with POR_EL1 on arm64. I
mentioned on the cover letter that resetting POR_EL1 on exception entry
is required (and not done yet), but in fact as you say it also needs to
be context-switched per-thread. This does sound pretty similar to GPRs
(unlike POR_EL0, which is switched in __switch_to() like the user TLS
register for instance).

Is there a particular concern about that extra switching? I don't expect
it to be a significant cost on arm64. In the vast majority of cases,
POR_EL1 will remain set to its default value, meaning that the overhead
is limited to reading POR_EL1, a load and a branch. The only situation
where an expensive write to POR_EL1 is needed is an interrupt firing
right in the middle of a page table setter - possible but pretty
unlikely. Writing to POR_EL1 on exception return isn't really a concern
either, as no additional barrier (ISB) is required in that case.

By the way thank your for mentioning the x86 attempt, I wasn't aware of
it. I'll have a better look and make sure to Cc anyone involved in that
work in future versions.

- Kevin