Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.user > #191444 > unrolled thread

Question on CVE-2017-5754 on Debian 8.9

Started byNicholas Geovanis <nickgeovanis@gmail.com>
First post2018-01-23 22:10 +0100
Last post2018-01-25 23:40 +0100
Articles 20 on this page of 64 — 14 participants

Back to article view | Back to linux.debian.user


Contents

  Question on CVE-2017-5754 on Debian 8.9 Nicholas Geovanis <nickgeovanis@gmail.com> - 2018-01-23 22:10 +0100
    Re: Question on CVE-2017-5754 on Debian 8.9 Sven Hartge <sven@svenhartge.de> - 2018-01-23 22:20 +0100
      Re: Question on CVE-2017-5754 on Debian 8.9 Nicholas Geovanis <nickgeovanis@gmail.com> - 2018-01-23 22:40 +0100
        Re: Question on CVE-2017-5754 on Debian 8.9 Sven Hartge <sven@svenhartge.de> - 2018-01-23 22:40 +0100
      Re: Question on CVE-2017-5754 on Debian 8.9 Michael Fothergill <michael.fothergill@gmail.com> - 2018-01-23 23:10 +0100
        Re: Question on CVE-2017-5754 on Debian 8.9 Michael Fothergill <michael.fothergill@gmail.com> - 2018-01-23 23:50 +0100
          Re: Question on CVE-2017-5754 on Debian 8.9 Richard Hector <richard@walnut.gen.nz> - 2018-01-24 00:00 +0100
            Re: Question on CVE-2017-5754 on Debian 8.9 Nicholas Geovanis <nickgeovanis@gmail.com> - 2018-01-24 00:10 +0100
              Re: Question on CVE-2017-5754 on Debian 8.9 Jonathan Dowland <jmtd@debian.org> - 2018-01-24 11:20 +0100
                Re: Question on CVE-2017-5754 on Debian 8.9 Nicholas Geovanis <nickgeovanis@gmail.com> - 2018-01-24 17:10 +0100
                  Re: Question on CVE-2017-5754 on Debian 8.9 Nicholas Geovanis <nickgeovanis@gmail.com> - 2018-01-24 19:20 +0100
            Re: Question on CVE-2017-5754 on Debian 8.9 Nicholas Geovanis <nickgeovanis@gmail.com> - 2018-01-24 00:10 +0100
              Re: Question on CVE-2017-5754 on Debian 8.9 Michael Stone <mstone@debian.org> - 2018-01-24 00:20 +0100
                Re: Question on CVE-2017-5754 on Debian 8.9 Richard Hector <richard@walnut.gen.nz> - 2018-01-24 02:20 +0100
            Re: Question on CVE-2017-5754 on Debian 8.9 Michael Fothergill <michael.fothergill@gmail.com> - 2018-01-24 12:20 +0100
              Re: Question on CVE-2017-5754 on Debian 8.9 Michael Fothergill <michael.fothergill@gmail.com> - 2018-01-24 12:40 +0100
                Re: Question on CVE-2017-5754 on Debian 8.9 Michael Fothergill <michael.fothergill@gmail.com> - 2018-01-24 13:10 +0100
                  Re: Question on CVE-2017-5754 on Debian 8.9 Michael Fothergill <michael.fothergill@gmail.com> - 2018-01-24 13:50 +0100
                    Re: Question on CVE-2017-5754 on Debian 8.9 Sven Hartge <sven@svenhartge.de> - 2018-01-24 14:10 +0100
                      Re: Question on CVE-2017-5754 on Debian 8.9 Michael Fothergill <michael.fothergill@gmail.com> - 2018-01-24 14:30 +0100
                        Re: Question on CVE-2017-5754 on Debian 8.9 Sven Hartge <sven@svenhartge.de> - 2018-01-24 14:50 +0100
                          Re: Question on CVE-2017-5754 on Debian 8.9 Vincent Lefevre <vincent@vinc17.net> - 2018-01-24 15:20 +0100
                            Re: Question on CVE-2017-5754 on Debian 8.9 Michael Fothergill <michael.fothergill@gmail.com> - 2018-01-24 15:40 +0100
                              Re: Question on CVE-2017-5754 on Debian 8.9 Michael Fothergill <michael.fothergill@gmail.com> - 2018-01-24 17:10 +0100
                                Re: Question on CVE-2017-5754 on Debian 8.9 Michael Fothergill <michael.fothergill@gmail.com> - 2018-01-24 17:30 +0100
                                Re: Question on CVE-2017-5754 on Debian 8.9 Greg Wooledge <wooledg@eeg.ccf.org> - 2018-01-24 17:30 +0100
                                  Re: Question on CVE-2017-5754 on Debian 8.9 Michael Fothergill <michael.fothergill@gmail.com> - 2018-01-24 18:10 +0100
                                    Re: Question on CVE-2017-5754 on Debian 8.9 The Wanderer <wanderer@fastmail.fm> - 2018-01-24 18:30 +0100
                                    Re: Question on CVE-2017-5754 on Debian 8.9 Greg Wooledge <wooledg@eeg.ccf.org> - 2018-01-24 18:40 +0100
                                      Re: Question on CVE-2017-5754 on Debian 8.9 Michael Fothergill <michael.fothergill@gmail.com> - 2018-01-24 19:10 +0100
                                      Re: Question on CVE-2017-5754 on Debian 8.9 Michael Fothergill <michael.fothergill@gmail.com> - 2018-01-24 19:20 +0100
                                        Re: Question on CVE-2017-5754 on Debian 8.9 Michael Fothergill <michael.fothergill@gmail.com> - 2018-01-24 19:40 +0100
                                          Re: Question on CVE-2017-5754 on Debian 8.9 Michael Fothergill <michael.fothergill@gmail.com> - 2018-01-24 21:30 +0100
                                            Re: Question on CVE-2017-5754 on Debian 8.9 Michael Lange <klappnase@freenet.de> - 2018-01-24 23:40 +0100
                                              Re: Question on CVE-2017-5754 on Debian 8.9 Michael Fothergill <michael.fothergill@gmail.com> - 2018-01-25 02:00 +0100
                                                Re: Question on CVE-2017-5754 on Debian 8.9 Michael Fothergill <michael.fothergill@gmail.com> - 2018-01-25 10:40 +0100
                                                  Re: Question on CVE-2017-5754 on Debian 8.9 Michael Lange <klappnase@freenet.de> - 2018-01-25 11:00 +0100
                                                    Re: Question on CVE-2017-5754 on Debian 8.9 Michael Fothergill <michael.fothergill@gmail.com> - 2018-01-25 13:00 +0100
                                                      Re: Question on CVE-2017-5754 on Debian 8.9 Michael Fothergill <michael.fothergill@gmail.com> - 2018-01-25 14:00 +0100
                                                        Re: Question on CVE-2017-5754 on Debian 8.9 Greg Wooledge <wooledg@eeg.ccf.org> - 2018-01-25 14:10 +0100
                                                          Re: Question on CVE-2017-5754 on Debian 8.9 Michael Fothergill <michael.fothergill@gmail.com> - 2018-01-25 14:40 +0100
                                                            Re: Question on CVE-2017-5754 on Debian 8.9 Michael Fothergill <michael.fothergill@gmail.com> - 2018-01-25 17:20 +0100
                                                              Re: Question on CVE-2017-5754 on Debian 8.9 Michael Lange <klappnase@freenet.de> - 2018-01-25 18:30 +0100
                                                                Re: Question on CVE-2017-5754 on Debian 8.9 Michael Fothergill <michael.fothergill@gmail.com> - 2018-01-25 19:40 +0100
                                                                  Re: Question on CVE-2017-5754 on Debian 8.9 Michael Fothergill <michael.fothergill@gmail.com> - 2018-01-25 19:50 +0100
                                                                    Re: Question on CVE-2017-5754 on Debian 8.9 Michael Lange <klappnase@freenet.de> - 2018-01-25 22:00 +0100
                                                                  Re: Question on CVE-2017-5754 on Debian 8.9 Brian <ad44@cityscape.co.uk> - 2018-01-25 20:30 +0100
                                                                    Re: Question on CVE-2017-5754 on Debian 8.9 Michael Fothergill <michael.fothergill@gmail.com> - 2018-01-25 22:00 +0100
                                                              Re: Question on CVE-2017-5754 on Debian 8.9 Michael Fothergill <michael.fothergill@gmail.com> - 2018-01-25 18:40 +0100
                                                                Re: Question on CVE-2017-5754 on Debian 8.9 Michael Lange <klappnase@freenet.de> - 2018-01-25 22:10 +0100
                                                                  Re: Question on CVE-2017-5754 on Debian 8.9 Michael Fothergill <michael.fothergill@gmail.com> - 2018-01-25 23:10 +0100
                                                                    Re: Question on CVE-2017-5754 on Debian 8.9 Michael Fothergill <michael.fothergill@gmail.com> - 2018-01-25 23:30 +0100
                                                                      Re: Question on CVE-2017-5754 on Debian 8.9 Michael Fothergill <michael.fothergill@gmail.com> - 2018-01-25 23:40 +0100
                                                                    Re: Question on CVE-2017-5754 on Debian 8.9 Michael Lange <klappnase@freenet.de> - 2018-01-25 23:40 +0100
                                                                      Re: Question on CVE-2017-5754 on Debian 8.9 Michael Fothergill <michael.fothergill@gmail.com> - 2018-01-26 00:10 +0100
                                                                        Re: Question on CVE-2017-5754 on Debian 8.9 Michael Lange <klappnase@freenet.de> - 2018-01-26 00:20 +0100
                                  Re: Question on CVE-2017-5754 on Debian 8.9 Michael Fothergill <michael.fothergill@gmail.com> - 2018-01-24 18:30 +0100
                                  Re: Question on CVE-2017-5754 on Debian 8.9 Vincent Lefevre <vincent@vinc17.net> - 2018-01-25 15:30 +0100
                                    Re: Question on CVE-2017-5754 on Debian 8.9 Greg Wooledge <wooledg@eeg.ccf.org> - 2018-01-25 15:40 +0100
                                      Re: Question on CVE-2017-5754 on Debian 8.9 David Wright <deblis@lionunicorn.co.uk> - 2018-01-25 16:10 +0100
                                      Re: Question on CVE-2017-5754 on Debian 8.9 Vincent Lefevre <vincent@vinc17.net> - 2018-01-25 23:20 +0100
                                  Re: Question on CVE-2017-5754 on Debian 8.9 Jochen Spieker <ml@well-adjusted.de> - 2018-01-25 21:30 +0100
                                    Re: Question on CVE-2017-5754 on Debian 8.9 Sven Joachim <svenjoac@gmx.de> - 2018-01-25 21:40 +0100
                                    Re: Question on CVE-2017-5754 on Debian 8.9 Vincent Lefevre <vincent@vinc17.net> - 2018-01-25 23:40 +0100

Page 1 of 4  [1] 2 3 4  Next page →


#191444 — Question on CVE-2017-5754 on Debian 8.9

FromNicholas Geovanis <nickgeovanis@gmail.com>
Date2018-01-23 22:10 +0100
SubjectQuestion on CVE-2017-5754 on Debian 8.9
Message-ID<vbdZn-7nW-9@gated-at.bofh.it>
I've installed the patch for CVE-2017-5754 as well as the microcode update:

# uname -a
Linux ftp51 3.16.0-5-amd64 #1 SMP Debian 3.16.51-3+deb8u1 (2018-01-08)
x86_64 GNU/Linux
# dmesg | grep isolation
[    0.000000] Kernel/User page tables isolation: enabled

And yet, the widely-recommended test script at
https://raw.githubusercontent.com/speed47/spectre-meltdown-checker/master/spectre-meltdown-checker.sh

...still reports that CVE-2017-5754 vulnerability exists (as well as
the other 2).

CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Kernel supports Page Table Isolation (PTI):  YES
* PTI enabled and active:  UNKNOWN  (dmesg truncated, please reboot
and relaunch this script)
* Checking if we're running under Xen PV (64 bits):  UNKNOWN  (dmesg
truncated, please reboot and relaunch this script)
> STATUS:  VULNERABLE  (PTI is needed to mitigate the vulnerability)

And for the record, this is not under Xen and as you see further
above, the kernel reports that PTI is indeed enabled.
So my question is: What have I missed? Is the test script flawed? Is
the fix flawed? Am I flawed?
Thanks....Nick

[toc] | [next] | [standalone]


#191445

FromSven Hartge <sven@svenhartge.de>
Date2018-01-23 22:20 +0100
Message-ID<vbe93-7rI-9@gated-at.bofh.it>
In reply to#191444
Nicholas Geovanis <nickgeovanis@gmail.com> wrote:

> I've installed the patch for CVE-2017-5754 as well as the microcode update:

Well, Intel majorly fscked up their microcodes and strongly recommends
to revert to an earlier BIOS/UEFI firmware (if possible) and also
advised all vendors shipping microcode as a separate package (meaning
VMware and all Linux vendors here) to revert to the version from
November 2017, which so far all major Linux distributions have done.

(Debian didn't even ship the update for Stable/Oldstable because the
problems where already showing two weeks ago.)

So, right now, unless you have the latest bleeding edge kernel, compiled
with a repoline-aware pre-release GCC, you will be vulnerable for
CVE-2017-5753 (Spectre#1) and CVE-2017-5715 (Spectre#2) for quite some
time.

> # uname -a
> Linux ftp51 3.16.0-5-amd64 #1 SMP Debian 3.16.51-3+deb8u1 (2018-01-08)
> x86_64 GNU/Linux
> # dmesg | grep isolation
> [    0.000000] Kernel/User page tables isolation: enabled

> And yet, the widely-recommended test script at
> https://raw.githubusercontent.com/speed47/spectre-meltdown-checker/master/spectre-meltdown-checker.sh

Did you run the script as root? Did you use the most recent version of
it? It gets developed quite rapidly, maybe you got a version which was
not correctly functioning at that moment, giving that you download the
script from the master-branch instead of one of the tagged releases.

S°

-- 
Sigmentation fault. Core dumped.

[toc] | [prev] | [next] | [standalone]


#191446

FromNicholas Geovanis <nickgeovanis@gmail.com>
Date2018-01-23 22:40 +0100
Message-ID<vbesp-7ya-1@gated-at.bofh.it>
In reply to#191445
On Tue, Jan 23, 2018 at 3:16 PM, Sven Hartge <sven@svenhartge.de> wrote:
> Nicholas Geovanis <nickgeovanis@gmail.com> wrote:
>
>> I've installed the patch for CVE-2017-5754 as well as the microcode update:
>
> So, right now, unless you have the latest bleeding edge kernel, compiled
> with a repoline-aware pre-release GCC, you will be vulnerable for
> CVE-2017-5753 (Spectre#1) and CVE-2017-5715 (Spectre#2) for quite some
> time.
>

Correct. But the installed fixes were for CVE-2017-5754 as I
mentioned, not for those two.

>> And yet, the widely-recommended test script at
>> https://raw.githubusercontent.com/speed47/spectre-meltdown-checker/master/spectre-meltdown-checker.sh
>
> Did you run the script as root?

Yes.

> Did you use the most recent version of
> it?

Yes.

> It gets developed quite rapidly, maybe you got a version which was
> not correctly functioning at that moment, giving that you download the
> script from the master-branch instead of one of the tagged releases.

OK, I'll do that again to ensure that I have the right one. Thanks very much.

> S°
>
> --
> Sigmentation fault. Core dumped.
>

[toc] | [prev] | [next] | [standalone]


#191447

FromSven Hartge <sven@svenhartge.de>
Date2018-01-23 22:40 +0100
Message-ID<vbesp-7ya-7@gated-at.bofh.it>
In reply to#191446
Nicholas Geovanis <nickgeovanis@gmail.com> wrote:
> On Tue, Jan 23, 2018 at 3:16 PM, Sven Hartge <sven@svenhartge.de> wrote:
>> Nicholas Geovanis <nickgeovanis@gmail.com> wrote:

>>> I've installed the patch for CVE-2017-5754 as well as the microcode update:

>> So, right now, unless you have the latest bleeding edge kernel, compiled
>> with a repoline-aware pre-release GCC, you will be vulnerable for
>> CVE-2017-5753 (Spectre#1) and CVE-2017-5715 (Spectre#2) for quite some
>> time.

> Correct. But the installed fixes were for CVE-2017-5754 as I
> mentioned, not for those two.

Sure. But there is no Microcode update fixing or even mitigating
CVE-2017-5754 (Meltdown). KPTI (or VA Shadowing as Microsoft calls it)
is the only workaround on affected CPUs (at the moment).

>>> And yet, the widely-recommended test script at
>>> https://raw.githubusercontent.com/speed47/spectre-meltdown-checker/master/spectre-meltdown-checker.sh
>>

>> It gets developed quite rapidly, maybe you got a version which was
>> not correctly functioning at that moment, giving that you download
>> the script from the master-branch instead of one of the tagged
>> releases.

> OK, I'll do that again to ensure that I have the right one. Thanks
> very much.

I can say: works for me, version
3e454f1817c447baab60990fc5c4b11ca9880c73 (Tue Jan 23 22:20:34 2018
+0100) on Linux 4.14.0-3-amd64 #1 SMP Debian 4.14.13-1 (2018-01-14)
x86_64 GNU/Linux

Grüße,
Sven.

-- 
Sigmentation fault. Core dumped.

[toc] | [prev] | [next] | [standalone]


#191449

FromMichael Fothergill <michael.fothergill@gmail.com>
Date2018-01-23 23:10 +0100
Message-ID<vbeVr-7XK-1@gated-at.bofh.it>
In reply to#191445

[Multipart message — attachments visible in raw view] — view raw

On 23 January 2018 at 21:16, Sven Hartge <sven@svenhartge.de> wrote:

> Nicholas Geovanis <nickgeovanis@gmail.com> wrote:
>
> > I've installed the patch for CVE-2017-5754 as well as the microcode
> update:
>
> Well, Intel majorly fscked up their microcodes and strongly recommends
> to revert to an earlier BIOS/UEFI firmware (if possible) and also
> advised all vendors shipping microcode as a separate package (meaning
> VMware and all Linux vendors here) to revert to the version from
> November 2017, which so far all major Linux distributions have done.
>
> (Debian didn't even ship the update for Stable/Oldstable because the
> problems where already showing two weeks ago.)
>
> So, right now, unless you have the latest bleeding edge kernel, compiled
> with a repoline-aware pre-release GCC, you will be vulnerable for
> CVE-2017-5753 (Spectre#1) and CVE-2017-5715 (Spectre#2) for quite some
> time.
>
>
​Hi there,  I am running kernel 4.14.14 under gentoo testing on an AMD
kaveri box.

The version of GCC I am using is 7.2.  Whether that means the reptoline
patch is working for me I am not quite sure but it could be I guess.....

Someone who is smarter than the average bear has written a patch for the
spectre problem with no performance penalty:

https://www.neowin.net/news/retpoline-patch-coming-to-linux-49-and-linux-414

​I am not sure if you can do this as debian testing or experimental.

Cheers

Michael Fothergill
​


> > # uname -a
> > Linux ftp51 3.16.0-5-amd64 #1 SMP Debian 3.16.51-3+deb8u1 (2018-01-08)
> > x86_64 GNU/Linux
> > # dmesg | grep isolation
> > [    0.000000] Kernel/User page tables isolation: enabled
>
> > And yet, the widely-recommended test script at
> > https://raw.githubusercontent.com/speed47/spectre-meltdown-
> checker/master/spectre-meltdown-checker.sh
>
> Did you run the script as root? Did you use the most recent version of
> it? It gets developed quite rapidly, maybe you got a version which was
> not correctly functioning at that moment, giving that you download the
> script from the master-branch instead of one of the tagged releases.
>
> S°
>
> --
> Sigmentation fault. Core dumped.
>
>

[toc] | [prev] | [next] | [standalone]


#191453

FromMichael Fothergill <michael.fothergill@gmail.com>
Date2018-01-23 23:50 +0100
Message-ID<vbfy9-8b1-7@gated-at.bofh.it>
In reply to#191449

[Multipart message — attachments visible in raw view] — view raw

>>
> ​Hi there,  I am running kernel 4.14.14 under gentoo testing on an AMD
> kaveri box.
>
> The version of GCC I am using is 7.2.  Whether that means the reptoline
> patch is working for me I am not quite sure but it could be I guess.....
>
> Someone who is smarter than the average bear has written a patch for the
> spectre problem with no performance penalty:
>
> https://www.neowin.net/news/retpoline-patch-coming-to-
> linux-49-and-linux-414
>
> ​I am not sure if you can do this as debian testing or experimental.
>
> Cheers
>
> Michael Fothergill
>

​You can compile the kernel in debian:​

> ​https://www.debian.org/releases/jessie/i386/ch08s06.html.en
>

​There is also a debian page on gcc7
​
https://wiki.debian.org/GCC7

​If I ask the gentoo folks they will tell me if the KPTI and retpoline
patches are turned on automatically in kernel 4.14.14
or if you have to set a specific flag when you run make menuconfig (runs in
Debian too); then if GCC7 is new enough for this
you are good to go......

Cheers

MF

[toc] | [prev] | [next] | [standalone]


#191455

FromRichard Hector <richard@walnut.gen.nz>
Date2018-01-24 00:00 +0100
Message-ID<vbfHP-8ei-5@gated-at.bofh.it>
In reply to#191453

[Multipart message — attachments visible in raw view] — view raw

On 24/01/18 11:27, Michael Fothergill wrote:
> 
> 
> 
> 
> 
>     ​Hi there,  I am running kernel 4.14.14 under gentoo testing on an
>     AMD kaveri box.
> 
>     The version of GCC I am using is 7.2.  Whether that means the
>     reptoline patch is working for me I am not quite sure but it could
>     be I guess.....
> 
>     Someone who is smarter than the average bear has written a patch for
>     the spectre problem with no performance penalty:
> 
>     https://www.neowin.net/news/retpoline-patch-coming-to-linux-49-and-linux-414
>     <https://www.neowin.net/news/retpoline-patch-coming-to-linux-49-and-linux-414>
> 
>     ​I am not sure if you can do this as debian testing or experimental.
> 
>     Cheers
> 
>     Michael Fothergill
> 
> 
> ​You can compile the kernel in debian:​
> 
>     ​https://www.debian.org/releases/jessie/i386/ch08s06.html.en
> 
> 
> ​There is also a debian page on gcc7
> ​
> https://wiki.debian.org/GCC7
> 
> ​If I ask the gentoo folks they will tell me if the KPTI and retpoline
> patches are turned on automatically in kernel 4.14.14
> or if you have to set a specific flag when you run make menuconfig (runs
> in Debian too); then if GCC7 is new enough for this
> you are good to go......

The neowin link above has a link to a Phoronix article[1], which
suggests you need GCC 8.0, or maybe 7.3 if a backport succeeds. That was
9 days ago, of course ... Stretch only has 6.3, and even sid only has
7.2, so I don't see it hitting debian soon.

Richard

[1]
https://www.phoronix.com/scan.php?page=news_item&px=Linux-4.9-4.14-Retpoline

[toc] | [prev] | [next] | [standalone]


#191457

FromNicholas Geovanis <nickgeovanis@gmail.com>
Date2018-01-24 00:10 +0100
Message-ID<vbfRv-51-1@gated-at.bofh.it>
In reply to#191455
Sorry, should have added that the string "Linux version" also does not
appear in the dmesg results
after a reboot. So despite the check script's advice, a reboot doesn't
change the results here.

On Tue, Jan 23, 2018 at 5:02 PM, Nicholas Geovanis
<nickgeovanis@gmail.com> wrote:
> There was a newer version of the script (about 4 hours newer), but the
> new version yields the same result.
>
> So I have a debian 8.6 machine for which this test in the script is failing:
>         if ! dmesg | grep -qE '(^|\] )Linux version [0-9]'; then
>                 # dmesg truncated
>                 return 2
>         fi
>
> So on that one debian server, the string "Linux version" does _not_
> appear in dmesg output, like so:
> # dmesg | grep Linux
> [    0.564432] [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored
> [    1.108492] Linux agpgart interface v0.103
> [    2.192537] pps_core: LinuxPPS API ver. 1 registered
> [    2.209475] usb usb1: Manufacturer: Linux 3.16.0-5-amd64 ehci_hcd
> [    2.225593] usb usb2: Manufacturer: Linux 3.16.0-5-amd64 ehci_hcd
>
> So my question becomes: Is it just my server, or others too? And why me?
>
>
> On Tue, Jan 23, 2018 at 4:54 PM, Richard Hector <richard@walnut.gen.nz> wrote:
>> On 24/01/18 11:27, Michael Fothergill wrote:
>>>
>>>
>>>
>>>
>>>
>>>     Hi there,  I am running kernel 4.14.14 under gentoo testing on an
>>>     AMD kaveri box.
>>>
>>>     The version of GCC I am using is 7.2.  Whether that means the
>>>     reptoline patch is working for me I am not quite sure but it could
>>>     be I guess.....
>>>
>>>     Someone who is smarter than the average bear has written a patch for
>>>     the spectre problem with no performance penalty:
>>>
>>>     https://www.neowin.net/news/retpoline-patch-coming-to-linux-49-and-linux-414
>>>     <https://www.neowin.net/news/retpoline-patch-coming-to-linux-49-and-linux-414>
>>>
>>>     I am not sure if you can do this as debian testing or experimental.
>>>
>>>     Cheers
>>>
>>>     Michael Fothergill
>>>
>>>
>>> You can compile the kernel in debian:
>>>
>>>     https://www.debian.org/releases/jessie/i386/ch08s06.html.en
>>>
>>>
>>> There is also a debian page on gcc7
>>>
>>> https://wiki.debian.org/GCC7
>>>
>>> If I ask the gentoo folks they will tell me if the KPTI and retpoline
>>> patches are turned on automatically in kernel 4.14.14
>>> or if you have to set a specific flag when you run make menuconfig (runs
>>> in Debian too); then if GCC7 is new enough for this
>>> you are good to go......
>>
>> The neowin link above has a link to a Phoronix article[1], which
>> suggests you need GCC 8.0, or maybe 7.3 if a backport succeeds. That was
>> 9 days ago, of course ... Stretch only has 6.3, and even sid only has
>> 7.2, so I don't see it hitting debian soon.
>>
>> Richard
>>
>> [1]
>> https://www.phoronix.com/scan.php?page=news_item&px=Linux-4.9-4.14-Retpoline
>>

[toc] | [prev] | [next] | [standalone]


#191469

FromJonathan Dowland <jmtd@debian.org>
Date2018-01-24 11:20 +0100
Message-ID<vbqjT-6OY-5@gated-at.bofh.it>
In reply to#191457
On Tue, Jan 23, 2018 at 05:07:15PM -0600, Nicholas Geovanis wrote:
>Sorry, should have added that the string "Linux version" also does not
>appear in the dmesg results
>after a reboot. So despite the check script's advice, a reboot doesn't
>change the results here.

Sylvestre Ledru has uploaded the script to the Debian archive (package
spectre-meltdown-checker in sid). I haven't checked but they might have
made any necessary alterations for it to perform properly on Debian
systems. It might be worth trying that version. (if any alterations are
required for proper operation on Debian and are *not* made to the
packaged version of the script, a Debian bug is appropriate)

>On Tue, Jan 23, 2018 at 5:02 PM, Nicholas Geovanis
><nickgeovanis@gmail.com> wrote:
>> There was a newer version of the script (about 4 hours newer), but the
>> new version yields the same result.
>>
>> So I have a debian 8.6 machine for which this test in the script is failing:
(snip)

This test seems to be a "pre-test": it does not actually test for
whether PTI is enabled; it tests whether the kernel ring buffer has
rotated. There must be a subsequent test in the script to see whether
PTI has been enabled (that is not executed if the kernel ring buffer
has rotated).

If you can identify that subsequent test, *and* if you have your kernel
messages logged somewhere (/var/log/kern.log*, perhaps, or within
journald), then you could adapt the subsequent test to check against
those logs instead of the live ring buffer.

>> So my question becomes: Is it just my server, or others too? And why me?

Good question. Is this a VPS?

-- 

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄⠀⠀⠀⠀ Please do not CC me, I am subscribed to the list.

[toc] | [prev] | [next] | [standalone]


#191486

FromNicholas Geovanis <nickgeovanis@gmail.com>
Date2018-01-24 17:10 +0100
Message-ID<vbvMB-1W9-5@gated-at.bofh.it>
In reply to#191469
Jonathon Dowland the Great Lutenist wrote:
> Sylvestre Ledru has uploaded the script to the Debian archive (package
> spectre-meltdown-checker in sid). I haven't checked but they might have
> made any necessary alterations for it to perform properly on Debian
> systems. It might be worth trying that version. (if any alterations are
> required for proper operation on Debian and are *not* made to the
> packaged version of the script, a Debian bug is appropriate)

Thanks, I'm going to give that version a try shortly.

>> So my question becomes: Is it just my server, or others too? And why me?

> Good question. Is this a VPS?

No. Believe it or not, it's real Dell hardware. Just 700 miles away from me.

On Wed, Jan 24, 2018 at 4:13 AM, Jonathan Dowland <jmtd@debian.org> wrote:
> On Tue, Jan 23, 2018 at 05:07:15PM -0600, Nicholas Geovanis wrote:
>>
>> Sorry, should have added that the string "Linux version" also does not
>> appear in the dmesg results
>> after a reboot. So despite the check script's advice, a reboot doesn't
>> change the results here.
>
>
> Sylvestre Ledru has uploaded the script to the Debian archive (package
> spectre-meltdown-checker in sid). I haven't checked but they might have
> made any necessary alterations for it to perform properly on Debian
> systems. It might be worth trying that version. (if any alterations are
> required for proper operation on Debian and are *not* made to the
> packaged version of the script, a Debian bug is appropriate)
>
>> On Tue, Jan 23, 2018 at 5:02 PM, Nicholas Geovanis
>> <nickgeovanis@gmail.com> wrote:
>>>
>>> There was a newer version of the script (about 4 hours newer), but the
>>> new version yields the same result.
>>>
>>> So I have a debian 8.6 machine for which this test in the script is
>>> failing:
>
> (snip)
>
> This test seems to be a "pre-test": it does not actually test for
> whether PTI is enabled; it tests whether the kernel ring buffer has
> rotated. There must be a subsequent test in the script to see whether
> PTI has been enabled (that is not executed if the kernel ring buffer
> has rotated).
>
> If you can identify that subsequent test, *and* if you have your kernel
> messages logged somewhere (/var/log/kern.log*, perhaps, or within
> journald), then you could adapt the subsequent test to check against
> those logs instead of the live ring buffer.
>
>>> So my question becomes: Is it just my server, or others too? And why me?
>
>
> Good question. Is this a VPS?
>
> --
>
> ⢀⣴⠾⠻⢶⣦⠀
> ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
> ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
> ⠈⠳⣄⠀⠀⠀⠀ Please do not CC me, I am subscribed to the list.
>

[toc] | [prev] | [next] | [standalone]


#191500

FromNicholas Geovanis <nickgeovanis@gmail.com>
Date2018-01-24 19:20 +0100
Message-ID<vbxOp-37L-5@gated-at.bofh.it>
In reply to#191486
On Wed, Jan 24, 2018 at 10:06 AM, Nicholas Geovanis
<nickgeovanis@gmail.com> wrote:
> Jonathon Dowland the Great Lutenist wrote:
>> Sylvestre Ledru has uploaded the script to the Debian archive (package
>> spectre-meltdown-checker in sid). I haven't checked but they might have
>> made any necessary alterations for it to perform properly on Debian
>> systems. It might be worth trying that version. (if any alterations are
>> required for proper operation on Debian and are *not* made to the
>> packaged version of the script, a Debian bug is appropriate)
>
> Thanks, I'm going to give that version a try shortly.
>

Happy to report that the version of the script in sid properly detects
presence of the CVE-2017-5754 fix on
debian 8.6 jessie. So to sum up for debian: Don't use the version of
spectre-meltdown-checker hosted on
github for the developers, use instead the version in debian sid. Even
on the older jessie. I'll be at least trying
this script on 7 too, just for fun:

CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Kernel supports Page Table Isolation (PTI):  YES
* PTI enabled and active:  YES
* Checking if we're running under Xen PV (64 bits):  NO
> STATUS:  NOT VULNERABLE  (PTI mitigates the vulnerability)

A false sense of security is worse than no security at all, see --disclaimer
root@ftp51:/home/PRLSS/ngeovanis# cat /etc/debian_version
8.6



On Wed, Jan 24, 2018 at 10:06 AM, Nicholas Geovanis
<nickgeovanis@gmail.com> wrote:
> Jonathon Dowland the Great Lutenist wrote:
>> Sylvestre Ledru has uploaded the script to the Debian archive (package
>> spectre-meltdown-checker in sid). I haven't checked but they might have
>> made any necessary alterations for it to perform properly on Debian
>> systems. It might be worth trying that version. (if any alterations are
>> required for proper operation on Debian and are *not* made to the
>> packaged version of the script, a Debian bug is appropriate)
>
> Thanks, I'm going to give that version a try shortly.
>
>>> So my question becomes: Is it just my server, or others too? And why me?
>
>> Good question. Is this a VPS?
>
> No. Believe it or not, it's real Dell hardware. Just 700 miles away from me.
>
> On Wed, Jan 24, 2018 at 4:13 AM, Jonathan Dowland <jmtd@debian.org> wrote:
>> On Tue, Jan 23, 2018 at 05:07:15PM -0600, Nicholas Geovanis wrote:
>>>
>>> Sorry, should have added that the string "Linux version" also does not
>>> appear in the dmesg results
>>> after a reboot. So despite the check script's advice, a reboot doesn't
>>> change the results here.
>>
>>
>> Sylvestre Ledru has uploaded the script to the Debian archive (package
>> spectre-meltdown-checker in sid). I haven't checked but they might have
>> made any necessary alterations for it to perform properly on Debian
>> systems. It might be worth trying that version. (if any alterations are
>> required for proper operation on Debian and are *not* made to the
>> packaged version of the script, a Debian bug is appropriate)
>>
>>> On Tue, Jan 23, 2018 at 5:02 PM, Nicholas Geovanis
>>> <nickgeovanis@gmail.com> wrote:
>>>>
>>>> There was a newer version of the script (about 4 hours newer), but the
>>>> new version yields the same result.
>>>>
>>>> So I have a debian 8.6 machine for which this test in the script is
>>>> failing:
>>
>> (snip)
>>
>> This test seems to be a "pre-test": it does not actually test for
>> whether PTI is enabled; it tests whether the kernel ring buffer has
>> rotated. There must be a subsequent test in the script to see whether
>> PTI has been enabled (that is not executed if the kernel ring buffer
>> has rotated).
>>
>> If you can identify that subsequent test, *and* if you have your kernel
>> messages logged somewhere (/var/log/kern.log*, perhaps, or within
>> journald), then you could adapt the subsequent test to check against
>> those logs instead of the live ring buffer.
>>
>>>> So my question becomes: Is it just my server, or others too? And why me?
>>
>>
>> Good question. Is this a VPS?
>>
>> --
>>
>> ⢀⣴⠾⠻⢶⣦⠀
>> ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
>> ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
>> ⠈⠳⣄⠀⠀⠀⠀ Please do not CC me, I am subscribed to the list.
>>

[toc] | [prev] | [next] | [standalone]


#191458

FromNicholas Geovanis <nickgeovanis@gmail.com>
Date2018-01-24 00:10 +0100
Message-ID<vbfRv-51-3@gated-at.bofh.it>
In reply to#191455
There was a newer version of the script (about 4 hours newer), but the
new version yields the same result.

So I have a debian 8.6 machine for which this test in the script is failing:
        if ! dmesg | grep -qE '(^|\] )Linux version [0-9]'; then
                # dmesg truncated
                return 2
        fi

So on that one debian server, the string "Linux version" does _not_
appear in dmesg output, like so:
# dmesg | grep Linux
[    0.564432] [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored
[    1.108492] Linux agpgart interface v0.103
[    2.192537] pps_core: LinuxPPS API ver. 1 registered
[    2.209475] usb usb1: Manufacturer: Linux 3.16.0-5-amd64 ehci_hcd
[    2.225593] usb usb2: Manufacturer: Linux 3.16.0-5-amd64 ehci_hcd

So my question becomes: Is it just my server, or others too? And why me?


On Tue, Jan 23, 2018 at 4:54 PM, Richard Hector <richard@walnut.gen.nz> wrote:
> On 24/01/18 11:27, Michael Fothergill wrote:
>>
>>
>>
>>
>>
>>     Hi there,  I am running kernel 4.14.14 under gentoo testing on an
>>     AMD kaveri box.
>>
>>     The version of GCC I am using is 7.2.  Whether that means the
>>     reptoline patch is working for me I am not quite sure but it could
>>     be I guess.....
>>
>>     Someone who is smarter than the average bear has written a patch for
>>     the spectre problem with no performance penalty:
>>
>>     https://www.neowin.net/news/retpoline-patch-coming-to-linux-49-and-linux-414
>>     <https://www.neowin.net/news/retpoline-patch-coming-to-linux-49-and-linux-414>
>>
>>     I am not sure if you can do this as debian testing or experimental.
>>
>>     Cheers
>>
>>     Michael Fothergill
>>
>>
>> You can compile the kernel in debian:
>>
>>     https://www.debian.org/releases/jessie/i386/ch08s06.html.en
>>
>>
>> There is also a debian page on gcc7
>>
>> https://wiki.debian.org/GCC7
>>
>> If I ask the gentoo folks they will tell me if the KPTI and retpoline
>> patches are turned on automatically in kernel 4.14.14
>> or if you have to set a specific flag when you run make menuconfig (runs
>> in Debian too); then if GCC7 is new enough for this
>> you are good to go......
>
> The neowin link above has a link to a Phoronix article[1], which
> suggests you need GCC 8.0, or maybe 7.3 if a backport succeeds. That was
> 9 days ago, of course ... Stretch only has 6.3, and even sid only has
> 7.2, so I don't see it hitting debian soon.
>
> Richard
>
> [1]
> https://www.phoronix.com/scan.php?page=news_item&px=Linux-4.9-4.14-Retpoline
>

[toc] | [prev] | [next] | [standalone]


#191459

FromMichael Stone <mstone@debian.org>
Date2018-01-24 00:20 +0100
Message-ID<vbg1c-8J-13@gated-at.bofh.it>
In reply to#191458
On Tue, Jan 23, 2018 at 05:02:39PM -0600, Nicholas Geovanis wrote:
>So my question becomes: Is it just my server, or others too? And why me?

dmesg reads a ring buffer; there are a limited number of entries, after 
which the oldest lines are dropped to make room for newer lines. Relying 
on dmesg is bad in general for this reason. If you were to reboot and 
run the script immediately (before many new lines are added to dmesg) it 
will likely work. Unless you took specific steps to disable kpti on a 
kernel that supports it, it will be on. You can also look for 
"Kernel/User page tables isolation: enabled" in syslog or the journal 
(journalctl -b | grep isolation) which will typically retain logs for 
longer than the dmesg buffer.

Mike Stone

[toc] | [prev] | [next] | [standalone]


#191461

FromRichard Hector <richard@walnut.gen.nz>
Date2018-01-24 02:20 +0100
Message-ID<vbhTk-1kr-1@gated-at.bofh.it>
In reply to#191459

[Multipart message — attachments visible in raw view] — view raw

On 24/01/18 12:11, Michael Stone wrote:
> Unless you took specific steps to disable kpti on a kernel that supports
> it, it will be on.

Only if the CPU needs it, I think. It's enabled on my i5, but not on my
AMD or my atom.

Richard
(I'm on the list; please don't cc me)

[toc] | [prev] | [next] | [standalone]


#191474

FromMichael Fothergill <michael.fothergill@gmail.com>
Date2018-01-24 12:20 +0100
Message-ID<vbrfY-7mK-7@gated-at.bofh.it>
In reply to#191455

[Multipart message — attachments visible in raw view] — view raw

>
> The neowin link above has a link to a Phoronix article[1], which
> suggests you need GCC 8.0, or maybe 7.3 if a backport succeeds. That was
> 9 days ago, of course ... Stretch only has 6.3, and even sid only has
> 7.2, so I don't see it hitting debian soon.
>
> Richard
>
> [1]
> https://www.phoronix.com/scan.php?page=news_item&px=Linux-4.
> 9-4.14-Retpoline


​Some new patches are coming soon:

https://www.phoronix.com/scan.php?page=news_item&px=Spectre-Variant-One-Linux-4.16

​https://www.phoronix.com/scan.php?page=news_item&px=LLVM-Retpoline-Added

I have posted a query on the gentoo forum asking if I have a recent enough
version of gcc etc for the retpoline.

There is a test program you can install and run and it will tell you if
both the meltdown and spectre patched are installed which I will try out.

Looks like your all going to have to run the latest kernels....(J)

Regards

MF

[toc] | [prev] | [next] | [standalone]


#191475

FromMichael Fothergill <michael.fothergill@gmail.com>
Date2018-01-24 12:40 +0100
Message-ID<vbrzk-7tg-3@gated-at.bofh.it>
In reply to#191474

[Multipart message — attachments visible in raw view] — view raw

On 24 January 2018 at 10:53, Michael Fothergill <
michael.fothergill@gmail.com> wrote:

>
>
>
>>
>> The neowin link above has a link to a Phoronix article[1], which
>> suggests you need GCC 8.0, or maybe 7.3 if a backport succeeds. That was
>> 9 days ago, of course ... Stretch only has 6.3, and even sid only has
>> 7.2, so I don't see it hitting debian soon.
>>
>> Richard
>>
>> [1]
>> https://www.phoronix.com/scan.php?page=news_item&px=Linux-4.
>> 9-4.14-Retpoline
>
>
> ​Some new patches are coming soon:
>
> https://www.phoronix.com/scan.php?page=news_item&px=Spectre-
> Variant-One-Linux-4.16
>
> ​https://www.phoronix.com/scan.php?page=news_item&px=LLVM-Retpoline-Added
>
> I have posted a query on the gentoo forum asking if I have a recent enough
> version of gcc etc for the retpoline.
>
> There is a test program you can install and run and it will tell you if
> both the meltdown and spectre patched are installed which I will try out.
>
> Looks like your all going to have to run the latest kernels....(J)
>
> Regards
>
> MF
>


​PS I installed the spectre meltdown checker and ran it:djt
/home/mikef/spectre-meltdown-checker # ./spectre-meltdown-checker.sh
Spectre and Meltdown mitigation detection tool v0.32

Checking for vulnerabilities on current system
Kernel is Linux 4.14.14-gentoo #1 SMP Tue Jan 23 13:06:23 GMT 2018 x86_64
CPU is AMD A10-7850K Radeon R7, 12 Compute Cores 4C+8G

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Mitigated according to the /sys interface:  NO  (kernel confirms your
system is vulnerable)
> STATUS:  VULNERABLE  (Vulnerable)

CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigated according to the /sys interface:  NO  (kernel confirms your
system is vulnerable)
* Mitigation 1
  * Hardware support (CPU microcode)
    * Indirect Branch Restricted Speculation (IBRS)
      * SPEC_CTRL MSR is available:  NO
      * CPU indicates IBRS capability:  NO
    * Indirect Branch Prediction Barrier (IBPB)
      * PRED_CMD MSR is available:  NO
      * CPU indicates IBPB capability:  NO
  * Kernel is compiled with IBRS/IBPB support:  NO
  * Currently enabled features
    * IBRS enabled for Kernel space:  NO
    * IBRS enabled for User space:  NO
    * IBPB enabled:  NO
* Mitigation 2
  * Kernel compiled with retpoline option:  YES
  * Kernel compiled with a retpoline-aware compiler:  NO  (kernel reports
minimal retpoline compilation)
  * Retpoline enabled:  YES
> STATUS:  VULNERABLE  (Vulnerable: Minimal AMD ASM retpoline)

CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Mitigated according to the /sys interface:  YES  (kernel confirms that
your CPU is unaffected)
* Kernel supports Page Table Isolation (PTI):  YES
* PTI enabled and active:  NO
* Running under Xen PV (64 bits):  NO
> STATUS:  NOT VULNERABLE  (your CPU vendor reported your CPU model as not
vulnerable)

A false sense of security is worse than no security at all, see --disclaimer
djt /home/mikef/spectre-meltdown-checker #

ie it's there but GCC 7.2 can't install it.

If you look at the discussion here:

https://forums.gentoo.org/viewtopic-p-8174746.html#8174746

you will see that I need to install gcc 7.3.0rc1

time to compile your own kernels...

Cheers

MF






​




>
>
>
>
>
>
>
>
>

[toc] | [prev] | [next] | [standalone]


#191477

FromMichael Fothergill <michael.fothergill@gmail.com>
Date2018-01-24 13:10 +0100
Message-ID<vbs2l-7Yn-11@gated-at.bofh.it>
In reply to#191475

[Multipart message — attachments visible in raw view] — view raw

On 24 January 2018 at 11:21, Michael Fothergill <
michael.fothergill@gmail.com> wrote:

>
>
> On 24 January 2018 at 10:53, Michael Fothergill <
> michael.fothergill@gmail.com> wrote:
>
>>
>>
>>
>>>
>>> The neowin link above has a link to a Phoronix article[1], which
>>> suggests you need GCC 8.0, or maybe 7.3 if a backport succeeds. That was
>>> 9 days ago, of course ... Stretch only has 6.3, and even sid only has
>>> 7.2, so I don't see it hitting debian soon.
>>>
>>> Richard
>>>
>>> [1]
>>> https://www.phoronix.com/scan.php?page=news_item&px=Linux-4.
>>> 9-4.14-Retpoline
>>
>>
>> ​Some new patches are coming soon:
>>
>> https://www.phoronix.com/scan.php?page=news_item&px=Spectre-
>> Variant-One-Linux-4.16
>>
>> ​https://www.phoronix.com/scan.php?page=news_item&px=LLVM-Retpoline-Added
>>
>> I have posted a query on the gentoo forum asking if I have a recent
>> enough version of gcc etc for the retpoline.
>>
>> There is a test program you can install and run and it will tell you if
>> both the meltdown and spectre patched are installed which I will try out.
>>
>> Looks like your all going to have to run the latest kernels....(J)
>>
>> Regards
>>
>> MF
>>
>
>
> ​PS I installed the spectre meltdown checker and ran it:djt
> /home/mikef/spectre-meltdown-checker # ./spectre-meltdown-checker.sh
> Spectre and Meltdown mitigation detection tool v0.32
>
> Checking for vulnerabilities on current system
> Kernel is Linux 4.14.14-gentoo #1 SMP Tue Jan 23 13:06:23 GMT 2018 x86_64
> CPU is AMD A10-7850K Radeon R7, 12 Compute Cores 4C+8G
>
> CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
> * Mitigated according to the /sys interface:  NO  (kernel confirms your
> system is vulnerable)
> > STATUS:  VULNERABLE  (Vulnerable)
>
> CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
> * Mitigated according to the /sys interface:  NO  (kernel confirms your
> system is vulnerable)
> * Mitigation 1
>   * Hardware support (CPU microcode)
>     * Indirect Branch Restricted Speculation (IBRS)
>       * SPEC_CTRL MSR is available:  NO
>       * CPU indicates IBRS capability:  NO
>     * Indirect Branch Prediction Barrier (IBPB)
>       * PRED_CMD MSR is available:  NO
>       * CPU indicates IBPB capability:  NO
>   * Kernel is compiled with IBRS/IBPB support:  NO
>   * Currently enabled features
>     * IBRS enabled for Kernel space:  NO
>     * IBRS enabled for User space:  NO
>     * IBPB enabled:  NO
> * Mitigation 2
>   * Kernel compiled with retpoline option:  YES
>   * Kernel compiled with a retpoline-aware compiler:  NO  (kernel reports
> minimal retpoline compilation)
>   * Retpoline enabled:  YES
> > STATUS:  VULNERABLE  (Vulnerable: Minimal AMD ASM retpoline)
>
> CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
> * Mitigated according to the /sys interface:  YES  (kernel confirms that
> your CPU is unaffected)
> * Kernel supports Page Table Isolation (PTI):  YES
> * PTI enabled and active:  NO
> * Running under Xen PV (64 bits):  NO
> > STATUS:  NOT VULNERABLE  (your CPU vendor reported your CPU model as not
> vulnerable)
>
> A false sense of security is worse than no security at all, see
> --disclaimer
> djt /home/mikef/spectre-meltdown-checker #
>
> ie it's there but GCC 7.2 can't install it.
>
> If you look at the discussion here:
>
> https://forums.gentoo.org/viewtopic-p-8174746.html#8174746
>
> you will see that I need to install gcc 7.3.0rc1
>
> time to compile your own kernels...
>
> Cheers
>
> MF
>

​PPS

GCC 7.3 is coming soon:

​https://www.phoronix.com/scan.php?page=news_item&px=GCC-7.3-In-January

so, problem solved.....

>
>
>
>
>
>
> ​
>
>
>
>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>

[toc] | [prev] | [next] | [standalone]


#191478

FromMichael Fothergill <michael.fothergill@gmail.com>
Date2018-01-24 13:50 +0100
Message-ID<vbsF3-8hF-3@gated-at.bofh.it>
In reply to#191477

[Multipart message — attachments visible in raw view] — view raw

On 24 January 2018 at 11:52, Michael Fothergill <
michael.fothergill@gmail.com> wrote:

>
>
> On 24 January 2018 at 11:21, Michael Fothergill <
> michael.fothergill@gmail.com> wrote:
>
>>
>>
>> On 24 January 2018 at 10:53, Michael Fothergill <
>> michael.fothergill@gmail.com> wrote:
>>
>>>
>>>
>>>
>>>>
>>>> The neowin link above has a link to a Phoronix article[1], which
>>>> suggests you need GCC 8.0, or maybe 7.3 if a backport succeeds. That was
>>>> 9 days ago, of course ... Stretch only has 6.3, and even sid only has
>>>> 7.2, so I don't see it hitting debian soon.
>>>>
>>>> Richard
>>>>
>>>> [1]
>>>> https://www.phoronix.com/scan.php?page=news_item&px=Linux-4.
>>>> 9-4.14-Retpoline
>>>
>>>
>>> ​Some new patches are coming soon:
>>>
>>> https://www.phoronix.com/scan.php?page=news_item&px=Spectre-
>>> Variant-One-Linux-4.16
>>>
>>> ​https://www.phoronix.com/scan.php?page=news_item&px=LLVM-Re
>>> tpoline-Added
>>>
>>> I have posted a query on the gentoo forum asking if I have a recent
>>> enough version of gcc etc for the retpoline.
>>>
>>> There is a test program you can install and run and it will tell you if
>>> both the meltdown and spectre patched are installed which I will try out.
>>>
>>> Looks like your all going to have to run the latest kernels....(J)
>>>
>>> Regards
>>>
>>> MF
>>>
>>
>>
>> ​PS I installed the spectre meltdown checker and ran it:djt
>> /home/mikef/spectre-meltdown-checker # ./spectre-meltdown-checker.sh
>> Spectre and Meltdown mitigation detection tool v0.32
>>
>> Checking for vulnerabilities on current system
>> Kernel is Linux 4.14.14-gentoo #1 SMP Tue Jan 23 13:06:23 GMT 2018 x86_64
>> CPU is AMD A10-7850K Radeon R7, 12 Compute Cores 4C+8G
>>
>> CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
>> * Mitigated according to the /sys interface:  NO  (kernel confirms your
>> system is vulnerable)
>> > STATUS:  VULNERABLE  (Vulnerable)
>>
>> CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
>> * Mitigated according to the /sys interface:  NO  (kernel confirms your
>> system is vulnerable)
>> * Mitigation 1
>>   * Hardware support (CPU microcode)
>>     * Indirect Branch Restricted Speculation (IBRS)
>>       * SPEC_CTRL MSR is available:  NO
>>       * CPU indicates IBRS capability:  NO
>>     * Indirect Branch Prediction Barrier (IBPB)
>>       * PRED_CMD MSR is available:  NO
>>       * CPU indicates IBPB capability:  NO
>>   * Kernel is compiled with IBRS/IBPB support:  NO
>>   * Currently enabled features
>>     * IBRS enabled for Kernel space:  NO
>>     * IBRS enabled for User space:  NO
>>     * IBPB enabled:  NO
>> * Mitigation 2
>>   * Kernel compiled with retpoline option:  YES
>>   * Kernel compiled with a retpoline-aware compiler:  NO  (kernel reports
>> minimal retpoline compilation)
>>   * Retpoline enabled:  YES
>> > STATUS:  VULNERABLE  (Vulnerable: Minimal AMD ASM retpoline)
>>
>> CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
>> * Mitigated according to the /sys interface:  YES  (kernel confirms that
>> your CPU is unaffected)
>> * Kernel supports Page Table Isolation (PTI):  YES
>> * PTI enabled and active:  NO
>> * Running under Xen PV (64 bits):  NO
>> > STATUS:  NOT VULNERABLE  (your CPU vendor reported your CPU model as
>> not vulnerable)
>>
>> A false sense of security is worse than no security at all, see
>> --disclaimer
>> djt /home/mikef/spectre-meltdown-checker #
>>
>> ie it's there but GCC 7.2 can't install it.
>>
>> If you look at the discussion here:
>>
>> https://forums.gentoo.org/viewtopic-p-8174746.html#8174746
>>
>> you will see that I need to install gcc 7.3.0rc1
>>
>> time to compile your own kernels...
>>
>> Cheers
>>
>> MF
>>
>
> ​PPS
>
> GCC 7.3 is coming soon:
>
> ​https://www.phoronix.com/scan.php?page=news_item&px=GCC-7.3-In-January
>
> so, problem solved....
>

​The link within the above one: ​
https://gcc.gnu.org/ml/gcc/2018-01/msg00148.html
​also has a link to the ftp download for the release candidate version of
gcc 7.3 ie 7.3.0rc1 which does actually work for spectre and retpoline.

So while waiting for the official release of 7.3. we could do a manual
installation of gcc 7.3.0 rc1 from the tar file and somehow uninstall the
current gcc deb file in stretch
and plumb in the manually compiled 7.3 rc1 edition into the debian install.

Then we can install the 4.14.14 kernel.

A doddle.



​






>
>>
>>
>>
>>
>> ​
>>
>>
>>
>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>

[toc] | [prev] | [next] | [standalone]


#191479

FromSven Hartge <sven@svenhartge.de>
Date2018-01-24 14:10 +0100
Message-ID<vbsYp-bv-5@gated-at.bofh.it>
In reply to#191478
Michael Fothergill <michael.fothergill@gmail.com> wrote:

> The link within the above one: 
> https://gcc.gnu.org/ml/gcc/2018-01/msg00148.html
> also has a link to the ftp download for the release candidate version of
> gcc 7.3 ie 7.3.0rc1 which does actually work for spectre and retpoline.

Debian Sid got gcc-7.3.0rc2 last night, the package is still named gcc-7
(7.2.0-20) though.

S°

-- 
Sigmentation fault. Core dumped.

[toc] | [prev] | [next] | [standalone]


#191480

FromMichael Fothergill <michael.fothergill@gmail.com>
Date2018-01-24 14:30 +0100
Message-ID<vbthM-hW-25@gated-at.bofh.it>
In reply to#191479

[Multipart message — attachments visible in raw view] — view raw

On 24 January 2018 at 12:58, Sven Hartge <sven@svenhartge.de> wrote:

> Michael Fothergill <michael.fothergill@gmail.com> wrote:
>
> > The link within the above one:
> > https://gcc.gnu.org/ml/gcc/2018-01/msg00148.html
> > also has a link to the ftp download for the release candidate version of
> > gcc 7.3 ie 7.3.0rc1 which does actually work for spectre and retpoline.
>
> Debian Sid got gcc-7.3.0rc2 last night, the package is still named gcc-7
> (7.2.0-20) though.
>

​Does that mean that if you upgrade to sid and installed gcc 7.2.0 you
would actually get 7.3.0rc2 in practice?

If so then you would then go ahead and manually compile kernel 4.14.14 and
you would be straight.

Cheers

MF​



>
> S°
>
> --
> Sigmentation fault. Core dumped.
>
>

[toc] | [prev] | [next] | [standalone]


Page 1 of 4  [1] 2 3 4  Next page →

Back to top | Article view | linux.debian.user


csiph-web