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]

Date:   Mon, 24 Oct 2016 23:39:47 +0300
From:   sonofagun@...nmailbox.org
To:     Borislav Petkov <bp@...en8.de>
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


> so that doesn't tell me a whole lot.
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...

> Well, Ontario is a small core and with the erratum workaround in place,
> it does get a bit worse too, apparently.
Yes but on C0 I got better results. Maybe the BIOS vendor got similar 
results and did not apply the fix. 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. Be carefull, you might hang your machine, brick your board 
or destroy your APU!

The truth is that my system behaves better with the patch.

The problem is that there is no way to get what I need! That is the 
E-300 datasheet...They give everything for the north and the south but 
we have poor documentation for the APU itself...I will contact AMD to 
see if I can get the APU datasheet so that we have a clue what those 
bits actualy do.

> Hohumm, yeah, the workaround impacts the number of branch misses. It
> probably disables some branch predictor optimization or so, which is
> "problematic" in certain scenarios.
That is obvious. You can't say what it does, it might disable an 
internal buffer or force a CPU subsystem to run at a lower frequency, 
who knows?

> I guess we still want it because first we should not explode and then 
> go
> fast :)
Exactly. I agree with that as I want to eliminate the crashes. Keep in 
mind that speed is something that all those APUs do not have and will 
never have, stability is what we are trying to improve.

> I'm thinking currently that if it is not easily triggerable, I could
> make the erratum workaround off by default and have a command line
> option which people can enable in case they experience any of the
> issues...
No problem, it is up to you. As I said above, I will not try to change 
your mind.