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. > >> Furthermore, I would hope that once a CPU is executing in userspace, it's >> not going to populate the TLB with kernel address translations - AIUI the >> whole vulnerability mitigation debacle was about preventing this sort of >> thing. > > Nope, unfortunately. There's two big exception to this. First, "implicit > supervisor-mode accesses". There are structures for which the CPU gets a > virtual address and accesses it even while userspace is running. The LDT > and GDT are the most obvious examples, but there are some less > ubiquitous ones like the buffers for PEBS events. > > Second, remember that user versus supervisor is determined *BY* the page > tables. Before Linear Address Space Separation (LASS), all virtual > memory accesses walk the page tables, even userspace accesses to kernel > addresses. The User/Supervisor bit is *in* the page tables, of course. > > A userspace access to a kernel address results in a page walk and the > CPU is completely free to cache all or part of that page walk. A > Meltdown-style _speculative_ userspace access to kernel memory won't > generate a fault either. It won't leak data like it used to, of course, > but it can still walk the page tables. That's one reason LASS is needed. Bummer, now I have at least two architectures proving me wrong :-) Thank you as well for the education, I really appreciate it.
