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

[Kevin Brodsky]

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