On 11/02/25 06:22, Dave Hansen wrote:
On 2/11/25 05:33, Valentin Schneider wrote:
- It's wrong to assume that TLB entries are only populated for
addresses you access - thanks to speculative execution, you have to assume that the CPU might be populating random TLB entries all over the place.
Gotta love speculation. Now it is supposed to be limited to genuinely accessible data & code, right? Say theoretically we have a full TLBi as literally the last thing before doing the return-to-userspace, speculation should be limited to executing maybe bits of the return-from-userspace code?
In practice, it's mostly limited like that.
Architecturally, there are no promises from the CPU. It is within its rights to cache anything from the page tables at any time. If it's in the CR3 tree, it's fair game.
So what if the VMEMMAP range *isn't* in the CR3 tree when a CPU is executing in userspace?
AIUI that's the case with kPTI - the remaining kernel pages should mostly be .entry.text and cpu_entry_area, at least for x86.
It sounds like it wouldn't do much for arm64 though, if with CnP a CPU executing in userspace and with the user/trampoline page table installed can still use TLB entries of another CPU executing in kernelspace with the kernel page table installed.