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: <7788de4607e9c16039ee34553fde8b35@openmailbox.org>
Date:   Tue, 25 Oct 2016 16:16:46 +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


> 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 I did not say that there is a linear correlation but that does not 
mean that those two numbers move opposite to each other. On all our 
systems running more tasks that consume more CPU and memory result in 
increased branch misses.
  It is normal as one thread might block another and a third thread might 
wait for the first thread to finish in order to resume.
  It is not normal to have increased misses only when the OS is loaded 
and running in idle without doing anything. Unless you are talking for 
AMD F14.

I wonder if we should just flush the L2 and disable it completely on AMD 
F14. Since this is an APU I have no idea if the onboard graphics can 
operate properly without L2.

> setpci -s 0x18.4 0x164.l
> 
> and looking at bit 2. If it is set, the erratum is fixed.
Will do but there is no meaning as I already told you on the first mail 
that D18F4x164 is 00000003h. It will not change.

> 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.
Yes I got it. I have no problem, you are free to do what you think is 
the best solution. Just ensure that it will not be possible to apply the 
fix to F16.

Even if you decide to not include the fix at all in the kernel, I still 
have the patch for my system and it works.

Did you get any crashes on your B0 box with Ubuntu? Is it a desktop 
system or a laptop?

The irony is that this laptop was bought without USB3 on purpose to 
achieve maximum stability... Luckily we didn't stick to the original 
plan to buy two laptops :)