Message-ID: <CA+i-1C1zN_GcLagTRgfJqT6uFoZaMZj1NUfxkvP7eG=VGQ0GGQ@mail.gmail.com>
Date: Wed, 13 Nov 2024 15:15:56 +0100
From: Brendan Jackman <jackmanb@...gle.com>
To: "Manwaring, Derek" <derekmn@...zon.com>
Cc: david.kaplan@....com, bp@...en8.de, dave.hansen@...ux.intel.com, 
	hpa@...or.com, jpoimboe@...nel.org, linux-kernel@...r.kernel.org, 
	mingo@...hat.com, pawan.kumar.gupta@...ux.intel.com, peterz@...radead.org, 
	tglx@...utronix.de, x86@...nel.org, mlipp@...zon.at, canellac@...zon.at
Subject: Re: [PATCH v2 19/35] Documentation/x86: Document the new attack
 vector controls

On Wed, 13 Nov 2024 at 04:58, Manwaring, Derek <derekmn@...zon.com> wrote:
> > I'm nervous about only doing the end-use controls and not the attack
> > vector controls because of the reasons outlined above.  For example, I'm
> > thinking about some proposed technologies such as KVM Address Space
> > Isolation which may go a long way to reducing the risk of guest->host
> > attacks but may not be fully secure yet (where the kernel would feel
> > comfortable disabling a bunch of guest->host protections automatically).
> > With attack vector-level controls, it would be easier to turn off
> > guest->host protection if the admin is comfortable with this technology,
> > but still leaving the (almost certainly needed) guest->guest protections
> > in place.
>
> Personally I wouldn't put too much weight on the possibility of
> disabling kernel mitigations with these future approaches. For what
> we're looking at with direct map removal, I would still keep kernel
> mitigations on unless we really needed one off. Brendan, I know you were
> looking at this differently though for ASI. What are your thoughts?

Yeah, personally my vision for ASI is more than it _is_ the
guest_host/guest_user mitigation and for the RFCv2 (long-awaited,
sorry) it will be the user_user/user_kernel mitigation too. If we
decide we wanna keep existing mitigations in place once ASI is at full
strength then ASI mostly failed. (Or perhaps to be more charitable to
ASI's strategic prospects, I'd feel OK if people said "I want ASI, but
I'll keep the old mitigations for defence-in-depth" as long as we
usually don't need to develop _new_ mitigations for those people).

So rather than saying "I have ASI, I can turn guest->host mitigation
off", you say "I have ASI, guest->host mitigation is very cheap, let's
have some champagne". In the utopian champagne future only very
advanced users will have any interest in more fine-grained questions
than "do I trust my KVM guests".

I guess another way to look at that is: the distinction in these pairs
of attack vectors is quite subtle. The fact that we are even
considering exposing users to that awkward subtle distinction
highlights a weakness of Linux's current mitigation posture and I
think ASI reduces that weakness. The weakness is: the cost of
mitigating attack vectors doesn't line up very well with the degree of
threat they present. We think it's kinda tricky in practice to steal
interesting data just by going into the kernel, but it's probably
possible, so we have to pay mitigation costs every time we go into the
kernel. Relatively low risk, relatively high cost. So we're having to
say to the user "do you wanna pay that high cost for this low risk? We
can't tell you how low it is though, we can only start rambling
incomprehensibly about something called the 'fizz map'".

At first I wanted to say the same thing about your work to remove
stuff from the direct map. Basically that's about architecting
ourselves towards a world where the "guest->kernel" attack vector just
isn't meaningful, right?

Powered by blists - more mailing lists