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
| ||
|
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/
Powered by blists - more mailing lists