Re: new cmdline parameter disable_cpu_features= (microcode update?)

[Borislav Petkov]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/