linux-kernel - Re: [PATCH] x86/cpufeatures: Cleanup AMD speculation feature bits

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] [day] [month] [year] [list]

Message-ID: <20180127131829.4kbi5mbqiqbbhbdw@pd.tnic>
Date:   Sat, 27 Jan 2018 14:18:29 +0100
From:   Borislav Petkov <bp@...en8.de>
To:     David Woodhouse <dwmw2@...radead.org>
Cc:     Tom Lendacky <thomas.lendacky@....com>, x86-ml <x86@...nel.org>,
        linux-tip-commits@...r.kernel.org, hpa@...or.com,
        gregkh@...uxfoundation.org, tglx@...utronix.de,
        linux-kernel@...r.kernel.org, mingo@...nel.org
Subject: Re: [PATCH] x86/cpufeatures: Cleanup AMD speculation feature bits

On Sat, Jan 27, 2018 at 10:32:26AM +0000, David Woodhouse wrote:
> No because cpuinfo should be information about the CPU.

That argument doesn't work in this case because we're already lying
there. Otherwise we would've never had the synthetic features in the
first place.

If you *really* wanna know what the CPU has, you use CPUID. Which is
also more or less a lie on virt, but that's a whole another story.

> For details of what mitigations are *actually* in use on this kernel,
> you want /sys/…/cpu/vulnerabilities, which might not even be
> readable by a non- root user.
>
> That's why I've used the names that we want to see in cpuinfo, for the
> basic CPU functionality.

So the sysfs nodes are perhaps an exception in this already exceptional
case due to the need to properly communicate mitigations.

Which kinda is the reason for why I'm advocating for common names in
/proc/cpuinfo and not having the hardware feature names which only
confuse people. And we do synthetic bits anyway. X86_BUG_ included.

> Does it exist, vs. whether the kernel is *using* it.

You can use the sysfs node for the latter.

Also, is it really using it doesn't always work: late microcode loading
which enables a CPUID bit but alternatves don't run late. Which is the
reason we said we won't do IBRS with late loading.

> The latter being a little bit of a hack because alternatives
> *only* let us do this stuff based on "CPU features", which is why
> X86_FEATURE_PTI exists.
>
> That one probably shouldn't be user-visible in /proc/cpuinfo *either*,
> should it?

Why not?

We have a lot of synthetic flags.

> I think I covered this, but for clarity: No, because the *hardware*
> feature is the one we want to be called just "ibpb" in /proc/cpuinfo.

I still see it the opposite way here: I'd much prefer to have
unified view in /proc/cpuinfo so that our communication outwards is
absolutely clear and simple: three feature flags. Regardless of box.
/sys/…/cpu/vulnerabilities being the additional thing for this
exceptional situation.

I don't really care about the actual feature bits. *Especially* since
not everything supports CPUID faulting so we can't even hide CPUID
from people on baremetal and they can find out what's really set there
anyway.

Btw, for example, ARM took "nopti" to be their chicken bit to disable
the ARM PTI mitigation too. It is much simpler for users if you have the
same names everywhere - so much so, that it even let's you get away with
a small lie.

Thx.

-- 
Regards/Gruss,
    Boris.

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