linux-kernel - Re: [PATCH] x86/AMD: Apply Erratum 688 fix when BIOS doesn't

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

Date:   Sun, 22 Oct 2017 13:12:10 +0200
From:   Borislav Petkov <bp@...en8.de>
To:     Ingo Molnar <mingo@...nel.org>
Cc:     X86 ML <x86@...nel.org>, Sherry Hurwitz <sherry.hurwitz@....com>,
        Yazen Ghannam <Yazen.Ghannam@....com>, mirh@...tonmail.ch,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] x86/AMD: Apply Erratum 688 fix when BIOS doesn't

On Sun, Oct 22, 2017 at 01:04:38PM +0200, Ingo Molnar wrote:
> Any objections to me adding a printk message that we applied a fix?
> 
> 	pr_info("x86/cpu/AMD: CPU erratum 688 worked around\n");
> 
> or so?
> 
> That would also create some pressure for customers to prod manufacturers to prod 
> BIOS makers to fix the erratum in a BIOS update or so.

Adding that would be purely useless because F14h is long out of
production AFAIK. Especially those earlier models.

So getting new BIOS for those is less likely than winning the lottery.
IOW, this is more or less, an after-the-fact fix for the remaining
machines out there.

Note that I didn't even use a bug flag because it would simply be a
waste.

Frankly, this fix could simply be a userspace script setting those two
MSR bits but then communicating it to people would be a nightmare, thus
the kernel fix.

Thx.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.