> On Jan 8, 2018, at 5:15 PM, Andrew Cooper <[email protected]> wrote: > >> On 09/01/2018 00:58, Linus Torvalds wrote: >>> On Mon, Jan 8, 2018 at 4:44 PM, Andi Kleen <[email protected]> wrote: >>> Essentially the RSB are hidden registers, and the only way to clear them >>> is the FILL_RETURN_BUFFER sequence. I don't see how clearing anything else >>> would help? >> Forget theory. Look at practice. >> >> Let's just assume that the attacker can write arbitrarily to the RSB >> state. Just accept it. >> >> If you accept that, then you turn the question instead into: are there >> things we can do to make that useless to an attacker. >> >> And there the point is that even if you control the RSB contents, you >> need to find something relevant to *put* in the RSB. You need to find >> the gadget that makes that control of the RSB useful. > > This is where the problem lies. An attacker with arbitrary control of > the RSB can redirect speculation arbitrarily. (And I agree, this is a > good default assumption to take). > > If SMEP is not active, speculation can go anywhere, including to a user > controlled gadget which can reload any registers it needs, including > with immediate constants.
I thought that, even on pre-SMEP hardware, the CPU wouldn't speculatively execute from NX pages. And PTI marks user memory NX in kernel mode. > > If SMEP is active, the attackers control of speculation is restricted to > supervisor executable mappings. > > The real question is whether it is worth special casing the SMEP-active > case given that for the SMEP-inactive case, your only viable option is > to refill the RSB and discard any potentially poisoned mappings. > > ~Andrew
