linux-kernel - Re: [PATCH 1/3] x86/cpu: Process all CPUID dependencies after identifying CPU info

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Y7XpTAFV6BLT8KgB@google.com>
Date:   Wed, 4 Jan 2023 21:02:04 +0000
From:   Sean Christopherson <seanjc@...gle.com>
To:     Borislav Petkov <bp@...en8.de>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
        Paolo Bonzini <pbonzini@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>, linux-kernel@...r.kernel.org,
        kvm@...r.kernel.org
Subject: Re: [PATCH 1/3] x86/cpu: Process all CPUID dependencies after
 identifying CPU info

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.