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 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

Powered by Openwall GNU/*/Linux Powered by OpenVZ