linux-kernel - Re: new cmdline parameter disable_cpu

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: <20160105113817.GE3718@pd.tnic>
Date:	Tue, 5 Jan 2016 12:38:17 +0100
From:	Borislav Petkov <bp@...en8.de>
To:	Piotr Dąbrowski <ultr@...r.pl>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: new cmdline parameter disable_cpu_features= (microcode update?)

On Tue, Jan 05, 2016 at 01:27:21AM +0100, Piotr Dąbrowski wrote:
> Is the microcode's header encrypted too?
> I thought there are two Processor Flags fields ('pf') available [1].
> Are they what I think they are?
> Is the header signed too, or only the actual microcode blob below the
> headers is?
> Sorry if I get it all wrong and there is no use for further discussion.

Yes, the microcode loader is completely wrong for what you're trying to
achieve. Just forget about it. :)

> Do you think there is any point in actually implementing the
> kernel-only disable_cpu_features= option upstream
> and then somehow convince the userland to respect flags reported by
> the kernel instead of those from the CPU?

I don't think there is any. Because you'd need to force *all* userspace
to not do CPUID but ask the kernel instead and that is a problem
because older kernels won't have the newer features enabled in, say
/proc/cpuinfo, and userspace would have to fallback to CPUID or older
tools won't have the code to check /proc/cpuinfo and would do CPUID
so...

This is going to be one helluva mess.

So I don't think we need to, or can, do anything here - the TSX f*ckup
was a nasty one and I'm not aware of any BIOS chicken bit with which
users can disable it. Which was a bad idea to not have it, in hindsight.
Otherwise there would *not* have been a microcode patch in the first
place. Which, for itself, was a pain to distribute and apply everywhere,
as you've seen.

And if we had a BIOS chicken bit, people would go into the BIOS, turn
TSX off, the CPUID bit would be clear too and userspace would've cleanly
fallen back to the old implementation and things would've worked
smoothly.

Now, if the kernel could control which CPUID bits are set and cleared,
then disable_cpu_features= would work. Unfortunately, this is not the
case. And this would require that all CPU features have corresponding
CPUID bits. Which is not the case either. :-\

Which brings me back to the BIOS chicken bits... :-)

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/