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

Message-ID: <CAEApFrjBJggQg+94ak9usynEgZhGPZwo7F+Dz6tPu45mc4XdnQ@mail.gmail.com>
Date:	Mon, 4 Jan 2016 23:55:57 +0100
From:	Piotr Dąbrowski <ultr@...r.pl>
To:	linux-kernel@...r.kernel.org
Cc:	Piotr Dąbrowski <ultr@...r.pl>
Subject: new cmdline parameter disable_cpu_features= (microcode update?)

Hello!

I would like to ask about a certain thing closely related to the
kernel's Microcode Update Driver.

Some new features of CPUs (namely TSX/HLE) have caused many problems
in the past (Intel's Haswell) and still continue to be a bleeding edge
technology especially when used with not yet well tested software
[1][2][3].
I thought it would be very handy to be able to temporarily disable
unwanted features of the CPU from the kernel cmdline level. So that
underlying libraries and programs do not know they are available, and
fallback to standard code.

I was in the middle of creating a patch for the disable_cpu_features=
kernel parameter when I realized that ignoring them just in the kernel
will not solve the problem.
Unfortunately glibc does not depend on the CPU flags reported by the
kernel, but by itself queries the CPU directly for its features [4].
And so can any other user-space program.

It seems the only reliable system-wide solution is to force a CPU
microcode update. And here comes my question, as I have no experience
in this area:
Would it be possible to apply only partial (CPU flags bits) microcode
update? Or extract the whole thing, change the requested flags (and
the checksum), and re-apply it?
Is such thing even possible? And would it be a reasonable thing to do
(maybe the rest of the microcode would break badly without the factory
flags set)?
What do you think?

Thank you for any tips on this topic.

[1] glibc hardware lock elision issues:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800574
[2] https://lists.debian.org/debian-glibc/2014/09/msg00076.html
Henrique de Moraes Holschuh <hmh@...ian.org>: "I recommend that lock
elision support in glibc should be disabled for Debian jessie. This
thing doesn't look nearly stable enough in glibc 2.19, and any bugs it
might cause *will be subtle*."
[3] nvidia proprietary driver's hardware lock elision bug:
https://devtalk.nvidia.com/default/topic/893325/newest-and-beta-linux-driver-causing-segmentation-fault-core-dumped-on-all-skylake-platforms/
[4] https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/x86_64/multiarch/init-arch.h;hb=78bd7499af46d739ce94410eaeea006e874ca9e5#l175
(ex. line 175)

Best Regards,
Piotr Dąbrowski
--
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/