On Thu, Dec 08, 2022, Borislav Petkov wrote: > On Thu, Dec 08, 2022 at 04:26:29PM +0000, Sean Christopherson wrote: > > But it's not really a hardware issue either. More like an admin/user issue. > > > > The problem is that if a kernel is built for subset of CPU types, e.g. just Intel > > or just Centaur, and then booted on an "unsupported" CPU type, init_ia32_feat_ctl() > > will never be invoked because ->c_init() will point a default_init(), and so the > > kernel never checks MSR_IA32_FEAT_CTL to see if VMX and/or SGX are fully enabled. > > Yeah, you called it an "edge case". I'm wondering whether we should even > worry about that case... > > I mean, the majority of Linuxes out there are allmodconfig-like kernels > and booting on unsupported CPU type doesn't happen. > > Hell, I'd even say that if you attempt booting on unsupported CPU type, > we should simply fail that boot attempt. > > I.e., what validate_cpu() does in some cases. > > IOW, I don't mind what you're doing but I wonder whether we should even > go the trouble to do so or simply deny that by saying "Well, don't do > that then". I agree with the "don't do that" sentiment, but IMO refusing to boot is too much. Unlike the validate_cpu() cases, the kernel can likely boot and run just fine, albeit with limited feature enabling. And there's a non-zero chance we'd end up with a kernel param to allow booting unknown CPUs, e.g. for people doing weird things with VMs or running old, esoteric hardware. At that point we'd end up with a more complex implementation than processing dependencies on synthetic flags, especially if there's ever a more legitimate need to process such dependencies.
