linux-kernel - Re: [PATCH] x86/AMD: Apply erratum 688 on machines without a BIOS fix

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]

Message-ID: <20161025092908.2dho2asz5ucojogw@pd.tnic>
Date:   Tue, 25 Oct 2016 11:29:08 +0200
From:   Borislav Petkov <bp@...en8.de>
To:     sonofagun@...nmailbox.org
Cc:     linux-kernel@...r.kernel.org, Nikos Barkas <levelwol@...il.com>
Subject: Re: [PATCH] x86/AMD: Apply erratum 688 on machines without a BIOS fix

On Mon, Oct 24, 2016 at 11:39:47PM +0300, sonofagun@...nmailbox.org wrote:
> It does to me! That cpu family is "broken" both on B0 and C0. I think
> that a CPU at 30% load should not have >31% branch misses. For example
> with 5% CPU usage you can't expect to get 10% branch-misses...

Why not? It all depends on the load type, working set and the access
patterns. There's no strong correlation between the load of a machine
and the amount of branch misses...

> Yes but on C0 I got better results. Maybe the BIOS vendor got similar
> results and did not apply the fix.

Well, there's a C0 stepping which doesn't need the fix because it was
fixed in the silicon.

You can check that by doing:

setpci -s 0x18.4 0x164.l

and looking at bit 2. If it is set, the erratum is fixed.

> They use the same BIOS for all machines B0, C0 and that could be the
> reason for not applying the 688 workaround. I think we are going to
> the wrong place here but I will not try to influence you at all. I
> only apply the fix once per boot and I think that we are not supposed
> to apply, remove and then reapply workarounds on the fly.

No, I don't mean that - I'm talking about *not* applying it by default
and when people start seeing issues like that, they can boot their
machines with something like "enable_e688_workaround" or so and it will
get applied then. I.e., an "opt-in" deal.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.