Re: [RFC PATCH v2 00/15] pkeys-based page table hardening
From: Kevin Brodsky <hidden>
Date: 2025-01-13 10:10:43
Also in:
linux-hardening, lkml
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