On Wed, Mar 31, 2021 at 08:46:18PM -0700, Dave Hansen wrote: > On 3/31/21 8:28 PM, Andi Kleen wrote: > >> The hardware (and VMMs and SEAM) have ways of telling the guest kernel > >> what is supported: CPUID. If it screws up, and the guest gets an > >> unexpected #VE, so be it. > > The main reason for disabling stuff is actually that we don't need > > to harden it. All these things are potential attack paths. > > Wait, MWAIT is an attack path? If it were an attack path, wouldn't it
No MWAIT is not, but lots of other things that can be controlled by the host are. And that will be a motivation to disable things. > >> We don't have all kinds of crazy handling in the kernel's #UD handler > >> just in case a CPU mis-enumerates a feature and we get a #UD. We have > >> to trust the underlying hardware to be sane. If it isn't, we die a > >> horrible death as fast as possible. Why should TDX be any different? > > That's what the original patch did -- no unnecessary checks -- but reviewers > > keep asking for the extra checks, so Sathya added more. We have the not > > unusual problem here that reviewers don't agree among themselves. > > Getting consensus is a pain in the neck, eh? Tt seems more like a circular argument currently. > > It's too bad all the reviewers in the community aren't like all of the > engineers at big companies where everyone always agrees. :) I would propose to go back to the original patch without all the extra checks. I think that's what you're arguing too. IIRC the person who originally requested extra checks was Andy, if he's ok with that too we can do it, so that you guys can finally move on to the other patches that actually do more than just trivial things. -Andi
