| 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
| ||
|
Message-ID: <20161024171450.yi6wixtdsxd4ea4c@pd.tnic>
Date: Mon, 24 Oct 2016 19:14:50 +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 04:13:25PM +0300, sonofagun@...nmailbox.org wrote:
> No command needed, just type: sudo perf stat -a and immediately exit
> with ctrl+C. That will give you a glimpse. See "% of all branches"
$ ./perf stat -a --repeat 10 sleep 1s
Performance counter stats for 'system wide' (10 runs):
2013.974964 cpu-clock (msec) # 1.999 CPUs utilized ( +- 0.02% )
88 context-switches # 0.044 K/sec ( +- 2.05% )
2 cpu-migrations # 0.001 K/sec ( +- 8.55% )
75 page-faults # 0.037 K/sec ( +- 0.42% )
81,177,296 cycles # 0.040 GHz ( +- 0.76% ) (66.62%)
0 stalled-cycles-frontend (66.63%)
0 stalled-cycles-backend # 0.00% backend cycles idle (66.64%)
9,602,846 instructions # 0.12 insn per cycle ( +- 2.08% ) (66.65%)
1,698,414 branches # 0.843 M/sec ( +- 4.26% ) (66.75%)
327,945 branch-misses # 19.31% of all branches ( +- 1.76% ) (66.72%)
1.007545371 seconds time elapsed ( +- 0.02% )
Now disable erratum workaround:
$ wrmsr --all 0xc0011021 0x10008000
$ rdmsr --all 0xc0011021
10008000
10008000
$ ./perf stat -a --repeat 10 sleep 1s
Performance counter stats for 'system wide' (10 runs):
2012.521775 cpu-clock (msec) # 1.999 CPUs utilized ( +- 0.02% )
91 context-switches # 0.045 K/sec ( +- 2.62% )
3 cpu-migrations # 0.001 K/sec ( +- 13.07% )
75 page-faults # 0.037 K/sec ( +- 0.66% )
82,215,531 cycles # 0.041 GHz ( +- 1.08% ) (66.60%)
0 stalled-cycles-frontend (66.60%)
0 stalled-cycles-backend # 0.00% backend cycles idle (66.62%)
9,444,884 instructions # 0.11 insn per cycle ( +- 2.11% ) (66.70%)
1,484,480 branches # 0.738 M/sec ( +- 5.16% ) (66.78%)
303,382 branch-misses # 20.44% of all branches ( +- 1.44% ) (66.70%)
1.006812225 seconds time elapsed ( +- 0.02% )
so that doesn't tell me a whole lot.
> next open firefox, rerun the same command after firefox launches and
> immediately exit with ctrl+C On that piece of crap I get branch-misses
> above 10% from boot without executing anything and perf does not like
> it so it displays it with red colour. On my quad core kabini APU,
> in order to get 9% branch-misses I have to open 50 tabs on firefox.
> Something is terribly wrong here.
Well, Ontario is a small core and with the erratum workaround in place,
it does get a bit worse too, apparently.
Let's see how many branch misses we get when starting firefox:
* with workaround:
$ echo 3 > /proc/sys/vm/drop_caches && ./perf stat ./firefox.sh
Performance counter stats for './firefox.sh':
257.037242 task-clock (msec) # 0.103 CPUs utilized
332 context-switches # 0.001 M/sec
6 cpu-migrations # 0.023 K/sec
1,022 page-faults # 0.004 M/sec
213,464,893 cycles # 0.830 GHz (63.29%)
0 stalled-cycles-frontend (62.76%)
0 stalled-cycles-backend # 0.00% backend cycles idle (66.88%)
106,763,405 instructions # 0.50 insn per cycle (73.54%)
23,794,511 branches # 92.572 M/sec (73.32%)
2,629,193 branch-misses # 11.05% of all branches (66.16%)
2.501140816 seconds time elapsed
* without it:
$ echo 3 > /proc/sys/vm/drop_caches && ./perf stat ./firefox.sh
Performance counter stats for './firefox.sh':
196.561165 task-clock (msec) # 0.082 CPUs utilized
276 context-switches # 0.001 M/sec
9 cpu-migrations # 0.046 K/sec
932 page-faults # 0.005 M/sec
162,697,731 cycles # 0.828 GHz (70.27%)
0 stalled-cycles-frontend (65.15%)
0 stalled-cycles-backend # 0.00% backend cycles idle (70.58%)
96,363,308 instructions # 0.59 insn per cycle (69.86%)
22,215,057 branches # 113.019 M/sec (61.63%)
935,833 branch-misses # 4.21% of all branches (66.72%)
2.392346081 seconds time elapsed
Btw, the script simply starts firefox, sleeps 2s and kills it.
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.
I guess we still want it because first we should not explode and then go
fast :)
> Yes, using Ubuntu 16.04 will just crash everything! For example I had
> crashes with the software updater program. Moreover firefox would become
> unresponsive even with one tab.
Ok, lemme install 16.04 on that box and see if I can reproduce.
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...
> Luckily initial tests of 16.10 seem promising as it is lighter and
> consumes 3~5% less RAM! Debian which was lighter was more responsive
> and had no crashes except an oops from adobe flash. I believe that the
> bug is triggered by the unusually high branch-misses specific to this
> machine. After the fix, I got better OS and program responsiveness.
Ok.
Thanks.
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
Powered by blists - more mailing lists