linux-kernel - Re: [PATCH v3 08/10] x86/setcpuid: Add kernel option setcpuid

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20190205061026.GB21801@zn.tnic>
Date:   Tue, 5 Feb 2019 07:10:26 +0100
From:   Borislav Petkov <bp@...en8.de>
To:     Fenghua Yu <fenghua.yu@...el.com>
Cc:     Dave Hansen <dave.hansen@...el.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, H Peter Anvin <hpa@...or.com>,
        Ashok Raj <ashok.raj@...el.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Michael Chan <michael.chan@...adcom.com>,
        Ravi V Shankar <ravi.v.shankar@...el.com>,
        Ricardo Neri <ricardo.neri@...el.com>,
        linux-kernel <linux-kernel@...r.kernel.org>, x86 <x86@...nel.org>
Subject: Re: [PATCH v3 08/10] x86/setcpuid: Add kernel option setcpuid

On Mon, Feb 04, 2019 at 02:14:30PM -0800, Fenghua Yu wrote:
> With "setcpuid=", there is no additional code to add as long as
> enumeration code is available.

Wait, are you saying that all the other enablement of new features is
easy and the only problem is patching {early_,}init_intel() so you'd
prefer not to patch it each time and use a cmdline param instead which
is error prone and really user-unfriendly?!

Usually, the patch adding the CPUID flag and checking is the easiest
one.

Also, you do realize that even if it gets applied, it will need
to sanity-check everything passed in, which means, it will accept
*only* the leafs which you guys don't have in CPUID?! It won't be a
lets-enable-this-random-cpuid-bits-and-see-what-happens deal.

Because I don't think anyone will be willing to debug reports from such
random enablements. The qemu+kvm "experiments" are already painful
enough.

By then you're better off simply patching {early_,}init_intel() I'd say.

> Every time a new feature like this case, the early_init_intel() needs
> to be changed for FMS etc.

Yes, as part of the enablement. You really seldomly - if ever at all -
have a new feature which only needs CPUID enablement. Unless it is some
feature flag to show support for new insns but that gets applied almost
immediately and I doubt userspace even uses it through /proc/cpuinfo -
they do their own querying of CPUID.

Because if they do the latter, setcpuid= will give you nothing unless we
enforce CPUID faulting. Except *that* is not present everywhere...

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.