On 11/02/25 14:03, Mark Rutland wrote: > On Tue, Feb 11, 2025 at 02:33:51PM +0100, Valentin Schneider wrote: >> On 10/02/25 23:08, Jann Horn 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? > > I think it's easier to ignore speculation entirely, and just assume that > the MMU can arbitrarily fill TLB entries from any page table entries > which are valid/accessible in the active page tables. Hardware > prefetchers can do that regardless of the specific path of speculative > execution. > > Thus TLB fills are not limited to VAs which would be used on that > return-to-userspace path. > >> 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. > > The CPU can definitely do that; the vulnerability mitigations are all > about what userspace can observe rather than what the CPU can do in the > background. Additionally, there are features like SPE and TRBE that use > kernel addresses while the CPU is executing userspace instructions. > > The latest ARM Architecture Reference Manual (ARM DDI 0487 L.a) is fairly clear > about that in section D8.16 "Translation Lookaside Buff", where it says > (among other things): > > When address translation is enabled, if a translation table entry > meets all of the following requirements, then that translation table > entry is permitted to be cached in a TLB or intermediate TLB caching > structure at any time: > • The translation table entry itself does not generate a Translation > fault, an Address size fault, or an Access flag fault. > • The translation table entry is not from a translation regime > configured by an Exception level that is lower than the current > Exception level. > > Here "permitted to be cached in a TLB" also implies that the HW is > allowed to fetch the translation tabl entry (which is what ARM call page > table entries). > That's actually fairly clear all things considered, thanks for the education and for fishing out the relevant DDI section! > The PDF can be found at: > > https://developer.arm.com/documentation/ddi0487/la/?lang=en > > Mark.
