On 11/02/25 06:22, Dave Hansen wrote: > On 2/11/25 05:33, Valentin Schneider wrote: >>> 2. 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.
