linux-kernel - Re: AMD errata 793 (CVE-2013-6885) needs a workaround in Linux?

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <52D55468.6000000@zytor.com>
Date:	Tue, 14 Jan 2014 07:14:48 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Borislav Petkov <bp@...en8.de>,
	Henrique de Moraes Holschuh <hmh@....eng.br>
CC:	X86 ML <x86@...nel.org>, LKML <linux-kernel@...r.kernel.org>
Subject: Re: AMD errata 793 (CVE-2013-6885) needs a workaround in Linux?

On 01/14/2014 03:55 AM, Borislav Petkov wrote:
> On Tue, Jan 14, 2014 at 09:41:33AM -0200, Henrique de Moraes Holschuh wrote:
>> I just got this assigned to amd64-microcode in Debian, but it is something
>> that needs to be worked around by the EFI/BIOS and/or the kernel.
>>
>> Since we all know just how well it pans out to depend on BIOS/EFI updates
>> for *anything*, I'm raising the issue here.  IMHO looks like it would be
>> worthwhile to either set the relevant MSR in the kernel if the BIOS didn't
>> do it, or at least warn the user of the need for a BIOS/EFI update...
>>
>> It is the usual hangs-core type of CPU errata (therefore, the best type
>> since it won't cause silent data corruption).  gcc-produced code managed to
>> trigger it (in DragonFly BSD).
> 
> I think this is a different issue than the dragonfly issue. In any case,
> if AMD delivers all BIOS with this workaround enabled, we don't need to
> do anything. And I asked them about it so we'll have an answer soon, I
> hope.
> 
> In any case, I'm on it.
> 

Seriously, though, if this MSR can be set at runtime without problems
(which covers 98% of all workarounds, but not 100%) then it seems like a
no-brainer to just do it as long as the offending CPUs can be identified
by the kernel.

	-hpa

--
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/