[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <543c5064-3ad8-4fb1-b05d-0772d7ce1d47@amazon.com>
Date: Tue, 19 Nov 2024 17:14:17 -0700
From: "Manwaring, Derek" <derekmn@...zon.com>
To: <jackmanb@...gle.com>
CC: <bp@...en8.de>, <canellac@...zon.at>, <dave.hansen@...ux.intel.com>,
<david.kaplan@....com>, <derekmn@...zon.com>, <hpa@...or.com>,
<jpoimboe@...nel.org>, <linux-kernel@...r.kernel.org>, <mingo@...hat.com>,
<mlipp@...zon.at>, <pawan.kumar.gupta@...ux.intel.com>,
<peterz@...radead.org>, <tglx@...utronix.de>, <x86@...nel.org>
Subject: Re: [PATCH v2 19/35] Documentation/x86: Document the new attack
vector controls
On 2024-11-13 at 14:15+0000, Brendan Jackman wrote:
> On Wed, 13 Nov 2024 at 04:58, Manwaring, Derek <derekmn@...zon.com> wrote:
> > 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?
>
> [...]
>
> 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?
Right, that is definitely the goal. The approach is like Microsoft
describes in the Secret-Free Hypervisor paper [1].
Call me belt-and-suspenders, but I prefer to leave mitigations in place
as well unless the performance is terrible. Like rappelling with a good
harness but still pad the fall zone.
Derek
[1] https://www.microsoft.com/en-us/research/uploads/prod/2022/07/sf-hypervisor.pdf
Powered by blists - more mailing lists