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

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

kernel 4.14.15 compilation using GCC 8 in unstable.......

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

Contents

  kernel 4.14.15 compilation using GCC 8 in unstable....... Michael Fothergill <michael.fothergill@gmail.com> - 2018-01-25 23:40 +0100
    Re: kernel 4.14.15 compilation using GCC 8 in unstable....... Michael Lange <klappnase@freenet.de> - 2018-01-26 00:40 +0100
      Re: kernel 4.14.15 compilation using GCC 8 in unstable....... Michael Fothergill <michael.fothergill@gmail.com> - 2018-01-26 15:30 +0100
        Re: kernel 4.14.15 compilation using GCC 8 in unstable....... Michael Lange <klappnase@freenet.de> - 2018-01-26 17:00 +0100
        Re: kernel 4.14.15 compilation using GCC 8 in unstable....... "tv.debian@googlemail.com" <tv.debian@googlemail.com> - 2018-01-26 17:10 +0100
          Re: kernel 4.14.15 compilation using GCC 8 in unstable....... Greg Wooledge <wooledg@eeg.ccf.org> - 2018-01-26 17:40 +0100
            Re: kernel 4.14.15 compilation using GCC 8 in unstable....... Michael Fothergill <michael.fothergill@gmail.com> - 2018-01-26 18:20 +0100
          Re: kernel 4.14.15 compilation using GCC 8 in unstable....... Michael Fothergill <michael.fothergill@gmail.com> - 2018-01-26 17:40 +0100
            Re: kernel 4.14.15 compilation using GCC 8 in unstable....... Michael Lange <klappnase@freenet.de> - 2018-01-26 17:50 +0100
            Re: kernel 4.14.15 compilation using GCC 8 in unstable....... Michael Fothergill <michael.fothergill@gmail.com> - 2018-01-26 17:50 +0100
              Re: kernel 4.14.15 compilation using GCC 8 in unstable....... Michael Fothergill <michael.fothergill@gmail.com> - 2018-01-26 18:00 +0100
          Re: kernel 4.14.15 compilation using GCC 8 in unstable....... Michael Lange <klappnase@freenet.de> - 2018-01-26 17:50 +0100
            Re: kernel 4.14.15 compilation using GCC 8 in unstable....... "tv.debian@googlemail.com" <tv.debian@googlemail.com> - 2018-01-26 18:00 +0100
              Re: kernel 4.14.15 compilation using GCC 8 in unstable....... Michael Lange <klappnase@freenet.de> - 2018-01-26 18:10 +0100
                Re: kernel 4.14.15 compilation using GCC 8 in unstable....... "tv.debian@googlemail.com" <tv.debian@googlemail.com> - 2018-01-26 18:20 +0100
                  Re: kernel 4.14.15 compilation using GCC 8 in unstable....... Michael Fothergill <michael.fothergill@gmail.com> - 2018-01-26 18:40 +0100
                    Re: kernel 4.14.15 compilation using GCC 8 in unstable....... Michael Fothergill <michael.fothergill@gmail.com> - 2018-01-26 18:50 +0100
                  Re: kernel 4.14.15 compilation using GCC 8 in unstable....... Michael Lange <klappnase@freenet.de> - 2018-01-26 18:50 +0100
                Re: kernel 4.14.15 compilation using GCC 8 in unstable....... Sven Hartge <sven@svenhartge.de> - 2018-01-26 18:40 +0100
                  Re: kernel 4.14.15 compilation using GCC 8 in unstable....... Michael Lange <klappnase@freenet.de> - 2018-01-26 21:00 +0100
                    Re: kernel 4.14.15 compilation using GCC 8 in unstable....... Sven Hartge <sven@svenhartge.de> - 2018-01-26 21:40 +0100
                      Re: kernel 4.14.15 compilation using GCC 8 in unstable....... Michael Lange <klappnase@freenet.de> - 2018-01-26 23:20 +0100
                        Re: kernel 4.14.15 compilation using GCC 8 in unstable....... Sven Hartge <sven@svenhartge.de> - 2018-01-26 23:30 +0100
                          Re: kernel 4.14.15 compilation using GCC 8 in unstable....... Michael Lange <klappnase@freenet.de> - 2018-01-26 23:50 +0100
                            Re: kernel 4.14.15 compilation using GCC 8 in unstable....... Sven Hartge <sven@svenhartge.de> - 2018-01-27 00:00 +0100
                              Re: kernel 4.14.15 compilation using GCC 8 in unstable....... Michael Lange <klappnase@freenet.de> - 2018-01-27 00:10 +0100
                            Re: kernel 4.14.15 compilation using GCC 8 in unstable....... Michael Lange <klappnase@freenet.de> - 2018-01-27 00:10 +0100
                              Re: kernel 4.14.15 compilation using GCC 8 in unstable....... Michael Fothergill <michael.fothergill@gmail.com> - 2018-01-27 11:50 +0100
                Re: kernel 4.14.15 compilation using GCC 8 in unstable....... Greg Wooledge <wooledg@eeg.ccf.org> - 2018-01-26 18:50 +0100
                  Re: kernel 4.14.15 compilation using GCC 8 in unstable....... Michael Lange <klappnase@freenet.de> - 2018-01-26 23:50 +0100
              Re: kernel 4.14.15 compilation using GCC 8 in unstable....... Michael Fothergill <michael.fothergill@gmail.com> - 2018-01-26 18:40 +0100
      Re: kernel 4.14.15 compilation using GCC 8 in unstable....... Michael Fothergill <michael.fothergill@gmail.com> - 2018-01-27 12:40 +0100
        Re: kernel 4.14.15 compilation using GCC 8 in unstable....... Michael Fothergill <michael.fothergill@gmail.com> - 2018-01-27 12:50 +0100
          Re: kernel 4.14.15 compilation using GCC 8 in unstable....... Michael Lange <klappnase@freenet.de> - 2018-01-27 13:10 +0100
            Re: kernel 4.14.15 compilation using GCC 8 in unstable....... Michael Fothergill <michael.fothergill@gmail.com> - 2018-01-27 13:40 +0100
            Re: kernel 4.14.15 compilation using GCC 8 in unstable....... Michael Fothergill <michael.fothergill@gmail.com> - 2018-01-27 13:40 +0100
              Re: kernel 4.14.15 compilation using GCC 8 in unstable....... Michael Lange <klappnase@freenet.de> - 2018-01-27 13:50 +0100
                Re: kernel 4.14.15 compilation using GCC 8 in unstable....... Michael Fothergill <michael.fothergill@gmail.com> - 2018-01-27 14:10 +0100
                  Re: kernel 4.14.15 compilation using GCC 8 in unstable....... Michael Fothergill <michael.fothergill@gmail.com> - 2018-01-27 14:20 +0100
                Re: kernel 4.14.15 compilation using GCC 8 in unstable....... Michael Fothergill <michael.fothergill@gmail.com> - 2018-01-27 14:40 +0100
                  Re: kernel 4.14.15 compilation using GCC 8 in unstable....... Michael Lange <klappnase@freenet.de> - 2018-01-27 14:50 +0100
                    Re: kernel 4.14.15 compilation using GCC 8 in unstable....... Michael Fothergill <michael.fothergill@gmail.com> - 2018-01-27 15:20 +0100
                    Re: kernel 4.14.15 compilation using GCC 8 in unstable....... Michael Fothergill <michael.fothergill@gmail.com> - 2018-01-27 15:40 +0100
                    Re: kernel 4.14.15 compilation using GCC 8 in unstable....... Michael Fothergill <michael.fothergill@gmail.com> - 2018-01-27 16:20 +0100
                      Re: kernel 4.14.15 compilation using GCC 8 in unstable....... "tv.debian@googlemail.com" <tv.debian@googlemail.com> - 2018-01-27 18:10 +0100
                        Re: kernel 4.14.15 compilation using GCC 8 in unstable....... Michael Lange <klappnase@freenet.de> - 2018-01-27 18:30 +0100
                          Re: kernel 4.14.15 compilation using GCC 8 in unstable....... "tv.debian@googlemail.com" <tv.debian@googlemail.com> - 2018-01-27 18:40 +0100
            Re: kernel 4.14.15 compilation using GCC 8 in unstable....... Michael Fothergill <michael.fothergill@gmail.com> - 2018-01-27 13:50 +0100
              Re: kernel 4.14.15 compilation using GCC 8 in unstable....... Michael Lange <klappnase@freenet.de> - 2018-01-27 14:30 +0100
                Re: kernel 4.14.15 compilation using GCC 8 in unstable....... Michael Fothergill <michael.fothergill@gmail.com> - 2018-01-27 14:50 +0100
          Re: kernel 4.14.15 compilation using GCC 8 in unstable....... Michael Fothergill <michael.fothergill@gmail.com> - 2018-01-27 13:30 +0100

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

#191566 — kernel 4.14.15 compilation using GCC 8 in unstable.......

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

Dear All,

I am continuing the discussion of the kernel 4.14.15 compilation in the
Question on CVE-2017-5754 on Debian 8.9 post in a new post.

The reason I am running with this kernel and not the 4.15.0 rc9 kernel that
is now available on kernel.org is that:

1. It is stable

2. I have never tried to compile a kernel in Debian before and want to make
it a bit easier for me the first time would try.

3.  kernel 4.14.15 does have the KPTI and retpoline patches in it, so it is
a fair candidate for the GCC8 compiler to produce a kernel that the patch
checker could confirm has these meltdown and spectre fixes are properly set
up and active.

Cheers

Regards

MF

[toc] | [next] | [standalone]

#191572

Hi,

On Thu, 25 Jan 2018 22:23:38 +0000
Michael Fothergill <michael.fothergill@gmail.com> wrote:

> Dear All,
> 
> I am continuing the discussion of the kernel 4.14.15 compilation in the
> Question on CVE-2017-5754 on Debian 8.9 post in a new post.
> 
> The reason I am running with this kernel and not the 4.15.0 rc9 kernel
> that is now available on kernel.org is that:
> 
> 1. It is stable
> 
> 2. I have never tried to compile a kernel in Debian before and want to
> make it a bit easier for me the first time would try.
> 
> 3.  kernel 4.14.15 does have the KPTI and retpoline patches in it, so
> it is a fair candidate for the GCC8 compiler to produce a kernel that
> the patch checker could confirm has these meltdown and spectre fixes
> are properly set up and active.

Ok, my advice if you don't want to give up yet :-)

Don't try to force the use of gcc-8 until you know that everything runs
properly with the default compiler.

Maybe you should follow the advice from the previously posted error
message:

"make[2]: Entering directory '/usr/src/linux-4.14.15'
Makefile:942: *** "Cannot generate ORC metadata for CONFIG_UNWINDER_ORC=y,
please install libelf-dev, libelf-devel or elfutils-libelf-devel".  Stop."
       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

(Ignore the messages about the debian directory.)
If similar messages as the above appear again, try to figure out what
needs to be additionally installed (some *-dev packages might still be
missing).

Once you get past the first few minutes of the procedure when using the
default compiler and you see how one module after the other is compiled,
hit Ctrl-C, do "make mrproper" and start over again with gcc-8.

This is just my 2¢, but I believe "debugging" one thing at a time is the
more promising approach here.

Good luck (and for now good night :)

Michael


.-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.

Virtue is a relative term.
		-- Spock, "Friday's Child", stardate 3499.1

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

#191592

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

On 25 January 2018 at 23:28, Michael Lange <klappnase@freenet.de> wrote:

> Hi,
>
> On Thu, 25 Jan 2018 22:23:38 +0000
> Michael Fothergill <michael.fothergill@gmail.com> wrote:
>
> > Dear All,
> >
> > I am continuing the discussion of the kernel 4.14.15 compilation in the
> > Question on CVE-2017-5754 on Debian 8.9 post in a new post.
> >
> > The reason I am running with this kernel and not the 4.15.0 rc9 kernel
> > that is now available on kernel.org is that:
> >
> > 1. It is stable
> >
> > 2. I have never tried to compile a kernel in Debian before and want to
> > make it a bit easier for me the first time would try.
> >
> > 3.  kernel 4.14.15 does have the KPTI and retpoline patches in it, so
> > it is a fair candidate for the GCC8 compiler to produce a kernel that
> > the patch checker could confirm has these meltdown and spectre fixes
> > are properly set up and active.
>
> Ok, my advice if you don't want to give up yet :-)
>
> Don't try to force the use of gcc-8 until you know that everything runs
> properly with the default compiler.
>
> Maybe you should follow the advice from the previously posted error
> message:
>
> "make[2]: Entering directory '/usr/src/linux-4.14.15'
> Makefile:942: *** "Cannot generate ORC metadata for CONFIG_UNWINDER_ORC=y,
> please install libelf-dev, libelf-devel or elfutils-libelf-devel".  Stop."
>        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>

​Many thanks.  I can think of some things that might help a bit here.

1. I could try out the ​
 gcc-help@gcc.gnu.org
​mailing list for suggestions on how to proceed here.​ They might know
which elf packages was important here etc.

2.  I could check the dependencies on the experimental page for the
compiler and see if the elf libraries are listed in it and then pick the
right one and install it.

3.  I could be cheered by the fact that gentoo has just made a basic build
file for gcc 7.3: (https://packages.gentoo.org/packages/sys-devel/gcc) - an
advert for gentoo I would say.

Regards

MF




> (Ignore the messages about the debian directory.)
> If similar messages as the above appear again, try to figure out what
> needs to be additionally installed (some *-dev packages might still be
> missing).
>
> Once you get past the first few minutes of the procedure when using the
> default compiler and you see how one module after the other is compiled,
> hit Ctrl-C, do "make mrproper" and start over again with gcc-8.
>
> This is just my 2¢, but I believe "debugging" one thing at a time is the
> more promising approach here.
>
> Good luck (and for now good night :)
>
> Michael
>
>
> .-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.
>
> Virtue is a relative term.
>                 -- Spock, "Friday's Child", stardate 3499.1
>
>

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

#191594

Hi,

On Fri, 26 Jan 2018 14:05:12 +0000
Michael Fothergill <michael.fothergill@gmail.com> wrote:

> >
> > "make[2]: Entering directory '/usr/src/linux-4.14.15'
> > Makefile:942: *** "Cannot generate ORC metadata for
> > CONFIG_UNWINDER_ORC=y, please install libelf-dev, libelf-devel or
> > elfutils-libelf-devel".  Stop."
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >
> 
> ​Many thanks.  I can think of some things that might help a bit here.
> 
> 1. I could try out the ​
>  gcc-help@gcc.gnu.org
> ​mailing list for suggestions on how to proceed here.​ They might know
> which elf packages was important here etc.

I guess you should just install libelf-dev and you'll get savely past
this point.

Regards

Michael



.-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.

There are always alternatives.
		-- Spock, "The Galileo Seven", stardate 2822.3

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

#191596

On 26/01/2018 19:35, Michael Fothergill wrote:
> On 25 January 2018 at 23:28, Michael Lange <klappnase@freenet.de> wrote:
> 
>> Hi,
>>
>> On Thu, 25 Jan 2018 22:23:38 +0000
>> Michael Fothergill <michael.fothergill@gmail.com> wrote:
>>
>>> Dear All,
>>>
>>> I am continuing the discussion of the kernel 4.14.15 compilation in the
>>> Question on CVE-2017-5754 on Debian 8.9 post in a new post.
>>>
>>> The reason I am running with this kernel and not the 4.15.0 rc9 kernel
>>> that is now available on kernel.org is that:
>>>
>>> 1. It is stable
>>>
>>> 2. I have never tried to compile a kernel in Debian before and want to
>>> make it a bit easier for me the first time would try.
>>>
>>> 3.  kernel 4.14.15 does have the KPTI and retpoline patches in it, so
>>> it is a fair candidate for the GCC8 compiler to produce a kernel that
>>> the patch checker could confirm has these meltdown and spectre fixes
>>> are properly set up and active.
>>
>> Ok, my advice if you don't want to give up yet :-)
>>
>> Don't try to force the use of gcc-8 until you know that everything runs
>> properly with the default compiler.
>>
>> Maybe you should follow the advice from the previously posted error
>> message:
>>
>> "make[2]: Entering directory '/usr/src/linux-4.14.15'
>> Makefile:942: *** "Cannot generate ORC metadata for CONFIG_UNWINDER_ORC=y,
>> please install libelf-dev, libelf-devel or elfutils-libelf-devel".  Stop."
>>         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>
> 
> ​Many thanks.  I can think of some things that might help a bit here.
> 
> 1. I could try out the ​
>   gcc-help@gcc.gnu.org
> ​mailing list for suggestions on how to proceed here.​ They might know
> which elf packages was important here etc.
> 
> 2.  I could check the dependencies on the experimental page for the
> compiler and see if the elf libraries are listed in it and then pick the
> right one and install it.
> 
> 3.  I could be cheered by the fact that gentoo has just made a basic build
> file for gcc 7.3: (https://packages.gentoo.org/packages/sys-devel/gcc) - an
> advert for gentoo I would say.
> 
> Regards
> 
> MF
> 
> 
> 
> 
>> (Ignore the messages about the debian directory.)
>> If similar messages as the above appear again, try to figure out what
>> needs to be additionally installed (some *-dev packages might still be
>> missing).
>>
>> Once you get past the first few minutes of the procedure when using the
>> default compiler and you see how one module after the other is compiled,
>> hit Ctrl-C, do "make mrproper" and start over again with gcc-8.
>>
>> This is just my 2¢, but I believe "debugging" one thing at a time is the
>> more promising approach here.
>>
>> Good luck (and for now good night :)
>>
>> Michael
>>
>>
>> .-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.
>>
>> Virtue is a relative term.
>>                  -- Spock, "Friday's Child", stardate 3499.1
>>
>>
> 

Hi, sorry to jump into the thread this late, I didn't follow the beginning.
You can save yourself quite a bit of hassle by downloading the upstream 
up-to-date vanilla kernel 4.15-rc9 and compile that with Unstable gcc-7.
All you need is there already and you will get as good a mitigation for 
Spectre as one can get right now. After configuration you can use the 
build target "make bindeb-pkg" or use the "make-kpkg" command from 
kernel-package (to be installed and configured, the doc will guide you).
Also you need basic build environment, and "libelf-dev" if you choose 
the ORC unwinder. For the build environment look at kernel-package 
dependencies.

If you want to stay mainly in Testing but cherry pick Unstable packages 
(and benefit from apt/aptitude dependencies resolution) you can look 
into apt-pinning, giving Unstable package a priority of 101 should do 
the trick, something like:

Package: *
Pin: release a=unstable
Pin-Priority: 101

in /etc/apt/preferences, coupled with:

APT::Default-Release "buster";

in /etc/apt/apt.conf


I would not pull critical packages from experimental unless it is 
absolutely necessary, dragons are lurking in there.

Hope it helps.

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

#191601

On Fri, Jan 26, 2018 at 04:17:27PM +0000, Michael Fothergill wrote:
> ​Is the sid gcc now 7.3 as someone said earlier even though it says it is
> 7.2?

Sid apparently has both "gcc" and "gcc-7" packages.

https://packages.debian.org/sid/gcc shows version 7.2.0-1d1.

https://packages.debian.org/sid/gcc-7 shows version 7.3.0-1.

As a sid user, YOU should be capable of performing this kind of search
(using apt-cache, apt, aptitude, http://packages.debian.org/ and other
resources).

As for whether the compiler implements whatever Spectre workaround
you're looking for ... who knows?  It's sid.  Test it and report
the results.  That's what sid is for.

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

#191610

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

On 26 January 2018 at 16:37, Greg Wooledge <wooledg@eeg.ccf.org> wrote:

> On Fri, Jan 26, 2018 at 04:17:27PM +0000, Michael Fothergill wrote:
> > ​Is the sid gcc now 7.3 as someone said earlier even though it says it is
> > 7.2?
>
> Sid apparently has both "gcc" and "gcc-7" packages.
>
> https://packages.debian.org/sid/gcc shows version 7.2.0-1d1.
>
> https://packages.debian.org/sid/gcc-7 shows version 7.3.0-1.
>
> As a sid user, YOU should be capable of performing this kind of search
> (using apt-cache, apt, aptitude, http://packages.debian.org/ and other
> resources).
>
> ​E.g. remote viewing.  I installed gcc7 but the other day but the compiler
installed was billed as 7.2.20 or something.

Maybe it's been upgraded since then.



> As for whether the compiler implements whatever Spectre workaround
> you're looking for ... who knows?  It's sid.  Test it and report
> the results.  That's what sid is for.
>

​If it really is gcc 7.3 it should be able to do it.

Regards

MF

​

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

#191602

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

>>
> Hi, sorry to jump into the thread this late, I didn't follow the beginning.
> You can save yourself quite a bit of hassle by downloading the upstream
> up-to-date vanilla kernel 4.15-rc9 and compile that with Unstable gcc-7.
> All you need is there already and you will get as good a mitigation for
> Spectre as one can get right now.


​Is the 7.2 kernel in sid gcc 7 really gassed up enough to compile the
spectre fix in a way that the meltdown-spectre checker will say that the
compiler used
was adequate to make the kernel fix work properly?​ A backport from GCC 8
to 7 has to be made to make it work - I thought this was only done in
7.3.......

​Is the sid gcc now 7.3 as someone said earlier even though it says it is
7.2?

I don't want to have to uninstall gcc 8 only to have to reinstall it again.

MF​




> After configuration you can use the build target "make bindeb-pkg" or use
> the "make-kpkg" command from kernel-package (to be installed and
> configured, the doc will guide you).
> Also you need basic build environment, and "libelf-dev" if you choose the
> ORC unwinder. For the build environment look at kernel-package dependencies.
>
> If you want to stay mainly in Testing but cherry pick Unstable packages
> (and benefit from apt/aptitude dependencies resolution) you can look into
> apt-pinning, giving Unstable package a priority of 101 should do the trick,
> something like:
>
> Package: *
> Pin: release a=unstable
> Pin-Priority: 101
>
> in /etc/apt/preferences, coupled with:
>
> APT::Default-Release "buster";
>
> in /etc/apt/apt.conf
>
>
> I would not pull critical packages from experimental unless it is
> absolutely necessary, dragons are lurking in there.
>
> Hope it helps.
>
>

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

#191603

On Fri, 26 Jan 2018 16:17:27 +0000
Michael Fothergill <michael.fothergill@gmail.com> wrote:

> >>
> > Hi, sorry to jump into the thread this late, I didn't follow the
> > beginning. You can save yourself quite a bit of hassle by downloading
> > the upstream up-to-date vanilla kernel 4.15-rc9 and compile that with
> > Unstable gcc-7. All you need is there already and you will get as
> > good a mitigation for Spectre as one can get right now.
> 
> 
> ​Is the 7.2 kernel in sid gcc 7 really gassed up enough to compile the
> spectre fix in a way that the meltdown-spectre checker will say that the
> compiler used
> was adequate to make the kernel fix work properly?​ A backport from GCC
> 8 to 7 has to be made to make it work - I thought this was only done in
> 7.3.......
> 
> ​Is the sid gcc now 7.3 as someone said earlier even though it says it
> is 7.2?
> 
> I don't want to have to uninstall gcc 8 only to have to reinstall it
> again.

Today gcc-7.3 arrived in sid, which seems to compile the kernel without
problems (see my previous post).

BTW, getting rid of gcc-8 was a bit of a pita, synaptic was no good for
that, had to do
# aptitude remove gcc-8-base
and follow the second suggestion, which fixed that issue here with a few
downgrades to the proper unstable versions. So please be careful what you
are doing in case you want to remove gcc-8.

Regards

Michael


.-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.

Vulcans believe peace should not depend on force.
		-- Amanda, "Journey to Babel", stardate 3842.3

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

#191605

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

On 26 January 2018 at 16:17, Michael Fothergill <
michael.fothergill@gmail.com> wrote:

>
>
>
>
>>>
>> Hi, sorry to jump into the thread this late, I didn't follow the
>> beginning.
>> You can save yourself quite a bit of hassle by downloading the upstream
>> up-to-date vanilla kernel 4.15-rc9 and compile that with Unstable gcc-7.
>> All you need is there already and you will get as good a mitigation for
>> Spectre as one can get right now.
>
>
> ​Is the 7.2 kernel in sid gcc 7 really gassed up enough to compile the
> spectre fix in a way that the meltdown-spectre checker will say that the
> compiler used
> was adequate to make the kernel fix work properly?
>

​Oops I made an error here. I meant to say:

Is the 7.2 version of the compiler in sid gcc 7 ​really gassed up enough to
compile the spectre fix in a way that the meltdown-spectre checker will say
that the compiler used
was adequate to make the kernel fix work properly?

Cheers

MF




> ​ A backport from GCC 8 to 7 has to be made to make it work - I thought
> this was only done in 7.3.......
>
> ​Is the sid gcc now 7.3 as someone said earlier even though it says it is
> 7.2?
>
> I don't want to have to uninstall gcc 8 only to have to reinstall it again.
>
> MF​
>
>
>
>
>> After configuration you can use the build target "make bindeb-pkg" or use
>> the "make-kpkg" command from kernel-package (to be installed and
>> configured, the doc will guide you).
>> Also you need basic build environment, and "libelf-dev" if you choose the
>> ORC unwinder. For the build environment look at kernel-package dependencies.
>>
>> If you want to stay mainly in Testing but cherry pick Unstable packages
>> (and benefit from apt/aptitude dependencies resolution) you can look into
>> apt-pinning, giving Unstable package a priority of 101 should do the trick,
>> something like:
>>
>> Package: *
>> Pin: release a=unstable
>> Pin-Priority: 101
>>
>> in /etc/apt/preferences, coupled with:
>>
>> APT::Default-Release "buster";
>>
>> in /etc/apt/apt.conf
>>
>>
>> I would not pull critical packages from experimental unless it is
>> absolutely necessary, dragons are lurking in there.
>>
>> Hope it helps.
>>
>>
>

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

#191606

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

On 26 January 2018 at 16:26, Michael Fothergill <
michael.fothergill@gmail.com> wrote:

>
>
> On 26 January 2018 at 16:17, Michael Fothergill <
> michael.fothergill@gmail.com> wrote:
>
>>
>>
>>
>>
>>>>
>>> Hi, sorry to jump into the thread this late, I didn't follow the
>>> beginning.
>>> You can save yourself quite a bit of hassle by downloading the upstream
>>> up-to-date vanilla kernel 4.15-rc9 and compile that with Unstable gcc-7.
>>> All you need is there already and you will get as good a mitigation for
>>> Spectre as one can get right now.
>>
>>
>> ​Is the 7.2 kernel in sid gcc 7 really gassed up enough to compile the
>> spectre fix in a way that the meltdown-spectre checker will say that the
>> compiler used
>> was adequate to make the kernel fix work properly?
>>
>
> ​Oops I made an error here. I meant to say:
>
> Is the 7.2 version of the compiler in sid gcc 7 ​really gassed up enough
> to compile the spectre fix in a way that the meltdown-spectre checker will
> say that the compiler used
> was adequate to make the kernel fix work properly?
>
> Cheers
>
> MF
>
>
>
>
>> ​ A backport from GCC 8 to 7 has to be made to make it work - I thought
>> this was only done in 7.3.......
>>
>> ​Is the sid gcc now 7.3 as someone said earlier even though it says it is
>> 7.2?
>>
>> I don't want to have to uninstall gcc 8 only to have to reinstall it
>> again.
>>
>> MF​
>>
>
​ie the backport here is installed:​


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



>
>>
>>
>>
>>> After configuration you can use the build target "make bindeb-pkg" or
>>> use the "make-kpkg" command from kernel-package (to be installed and
>>> configured, the doc will guide you).
>>> Also you need basic build environment, and "libelf-dev" if you choose
>>> the ORC unwinder. For the build environment look at kernel-package
>>> dependencies.
>>>
>>> If you want to stay mainly in Testing but cherry pick Unstable packages
>>> (and benefit from apt/aptitude dependencies resolution) you can look into
>>> apt-pinning, giving Unstable package a priority of 101 should do the trick,
>>> something like:
>>>
>>> Package: *
>>> Pin: release a=unstable
>>> Pin-Priority: 101
>>>
>>> in /etc/apt/preferences, coupled with:
>>>
>>> APT::Default-Release "buster";
>>>
>>> in /etc/apt/apt.conf
>>>
>>>
>>> I would not pull critical packages from experimental unless it is
>>> absolutely necessary, dragons are lurking in there.
>>>
>>> Hope it helps.
>>>
>>>
>>
>

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

#191604

Hi,

On Fri, 26 Jan 2018 21:34:51 +0530
"tv.debian@googlemail.com" <tv.debian@googlemail.com> wrote:

> Hi, sorry to jump into the thread this late, I didn't follow the
> beginning. You can save yourself quite a bit of hassle by downloading
> the upstream up-to-date vanilla kernel 4.15-rc9 and compile that with
> Unstable gcc-7. All you need is there already and you will get as good
> a mitigation for Spectre as one can get right now.

well, I just saw that gcc-7.3 arrived in sid today, so at least the
issues with gcc-8 from experimental seem to be history. 
As far as I know the gcc-7.2 that was the latest in sid until yesterday
was not the best option in this regard.

Just for the fun of it I got rid of gcc-8 now and upgraded to gcc-7.3; at
least now the kernel started to compile properly. Didn't have time right
now to let it finish though, since I had to boot again into stretch.
Probably there is a good chance that by tomorrow or so we can get a
kernel-image upgrade from sid anyway.

Regards

Michael



.-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.

I am pleased to see that we have differences.  May we together become
greater than the sum of both of us.
		-- Surak of Vulcan, "The Savage Curtain", stardate 5906.4

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

#191607

On 26/01/2018 22:08, Michael Lange wrote:
> Hi,
> 
> On Fri, 26 Jan 2018 21:34:51 +0530
> "tv.debian@googlemail.com" <tv.debian@googlemail.com> wrote:
> 
>> Hi, sorry to jump into the thread this late, I didn't follow the
>> beginning. You can save yourself quite a bit of hassle by downloading
>> the upstream up-to-date vanilla kernel 4.15-rc9 and compile that with
>> Unstable gcc-7. All you need is there already and you will get as good
>> a mitigation for Spectre as one can get right now.
> 
> well, I just saw that gcc-7.3 arrived in sid today, so at least the
> issues with gcc-8 from experimental seem to be history.
> As far as I know the gcc-7.2 that was the latest in sid until yesterday
> was not the best option in this regard.
> 
> Just for the fun of it I got rid of gcc-8 now and upgraded to gcc-7.3; at
> least now the kernel started to compile properly. Didn't have time right
> now to let it finish though, since I had to boot again into stretch.
> Probably there is a good chance that by tomorrow or so we can get a
> kernel-image upgrade from sid anyway.
> 
> Regards
> 
> Michael
> 
> 
> 
> .-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.
> 
> I am pleased to see that we have differences.  May we together become
> greater than the sum of both of us.
> 		-- Surak of Vulcan, "The Savage Curtain", stardate 5906.4
> 

gcc-7[.2] was really gcc-7.3-rc for a while, and was doing a good job at 
enabling Spectre mitigation (as tested by the spectre-meltdown-checker 
and /sys/devices/system/cpu/vulnerabilities/* entries).
No it is really gcc-7.3 and is fully capable.

I have not tested with a 4.4.15 kernel yet, but that should work too 
since most (all?) mitigation have been back-ported by now.

That leave the firmware/microcode as the ugly blind spot since we depend 
on chips and boards manufacturers to design and distribute working code.

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

#191609

On Fri, 26 Jan 2018 22:19:27 +0530
"tv.debian@googlemail.com" <tv.debian@googlemail.com> wrote:

> 
> gcc-7[.2] was really gcc-7.3-rc for a while, and was doing a good job
> at enabling Spectre mitigation (as tested by the
> spectre-meltdown-checker and /sys/devices/system/cpu/vulnerabilities/*
> entries). No it is really gcc-7.3 and is fully capable.
> 
> I have not tested with a 4.4.15 kernel yet, but that should work too 
> since most (all?) mitigation have been back-ported by now.

I am definitely anything but an expert on this; but with sid's 4.14.15
(which I assumed was compiled with said gcc-7.2) the script here says:

##########################################################
Hardware check
* Hardware support (CPU microcode) for mitigation techniques
  * Indirect Branch Restricted Speculation (IBRS)
    * SPEC_CTRL MSR is available:  UNKNOWN  (couldn't
read /dev/cpu/0/msr, is msr support enabled in your kernel?)
    * CPU indicates IBRS capability:  UNKNOWN  (couldn't
read /dev/cpu/0/cpuid, is cpuid support enabled in your kernel?)
  * Indirect Branch Prediction Barrier (IBPB)
    * PRED_CMD MSR is available:  UNKNOWN  (couldn't read /dev/cpu/0/msr,
is msr support enabled in your kernel?)
    * CPU indicates IBPB capability:  UNKNOWN  (couldn't
read /dev/cpu/0/cpuid, is cpuid support enabled in your kernel?)
  * Single Thread Indirect Branch Predictors (STIBP)
    * SPEC_CTRL MSR is available:  UNKNOWN  (couldn't
read /dev/cpu/0/msr, is msr support enabled in your kernel?)
    * CPU indicates STIBP capability:  UNKNOWN  (couldn't
read /dev/cpu/0/cpuid, is cpuid support enabled in your kernel?)
  * Enhanced IBRS (IBRS_ALL)
    * CPU indicates ARCH_CAPABILITIES MSR availability:  UNKNOWN
(couldn't read /dev/cpu/0/cpuid, is cpuid support enabled in your kernel?)
    * ARCH_CAPABILITIES MSR advertises IBRS_ALL capability:  NO
  * CPU explicitly indicates not being vulnerable to Meltdown (RDCL_NO):
NO
* CPU vulnerability to the three speculative execution attacks variants
  * Vulnerable to Variant 1:  YES
  * Vulnerable to Variant 2:  YES
  * Vulnerable to Variant 3:  NO

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
  * 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:  UNKNOWN  (dmesg truncated, please reboot and
relaunch this script)
* Running under Xen PV (64 bits):  UNKNOWN  (dmesg truncated, please
reboot and relaunch this script)
> 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

#######################################################

I have no idea though if this is due to my hardware, the compiler or the
kernel. Maybe for the fun of it I'll try to compile 4.15rc9 later with
that new gcc-7.3 and see what happens.

Regards

Michael

.-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.

I'm a soldier, not a diplomat.  I can only tell the truth.
		-- Kirk, "Errand of Mercy", stardate 3198.9

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

#191612

On 26/01/2018 22:37, Michael Lange wrote:
> On Fri, 26 Jan 2018 22:19:27 +0530
> "tv.debian@googlemail.com" <tv.debian@googlemail.com> wrote:
> 
>>
>> gcc-7[.2] was really gcc-7.3-rc for a while, and was doing a good job
>> at enabling Spectre mitigation (as tested by the
>> spectre-meltdown-checker and /sys/devices/system/cpu/vulnerabilities/*
>> entries). No it is really gcc-7.3 and is fully capable.
>>
>> I have not tested with a 4.4.15 kernel yet, but that should work too
>> since most (all?) mitigation have been back-ported by now.
> 
> I am definitely anything but an expert on this; but with sid's 4.14.15
> (which I assumed was compiled with said gcc-7.2) the script here says:
> 
> ##########################################################
> Hardware check
> * Hardware support (CPU microcode) for mitigation techniques
>    * Indirect Branch Restricted Speculation (IBRS)
>      * SPEC_CTRL MSR is available:  UNKNOWN  (couldn't
> read /dev/cpu/0/msr, is msr support enabled in your kernel?)
>      * CPU indicates IBRS capability:  UNKNOWN  (couldn't
> read /dev/cpu/0/cpuid, is cpuid support enabled in your kernel?)
>    * Indirect Branch Prediction Barrier (IBPB)
>      * PRED_CMD MSR is available:  UNKNOWN  (couldn't read /dev/cpu/0/msr,
> is msr support enabled in your kernel?)
>      * CPU indicates IBPB capability:  UNKNOWN  (couldn't
> read /dev/cpu/0/cpuid, is cpuid support enabled in your kernel?)
>    * Single Thread Indirect Branch Predictors (STIBP)
>      * SPEC_CTRL MSR is available:  UNKNOWN  (couldn't
> read /dev/cpu/0/msr, is msr support enabled in your kernel?)
>      * CPU indicates STIBP capability:  UNKNOWN  (couldn't
> read /dev/cpu/0/cpuid, is cpuid support enabled in your kernel?)
>    * Enhanced IBRS (IBRS_ALL)
>      * CPU indicates ARCH_CAPABILITIES MSR availability:  UNKNOWN
> (couldn't read /dev/cpu/0/cpuid, is cpuid support enabled in your kernel?)
>      * ARCH_CAPABILITIES MSR advertises IBRS_ALL capability:  NO
>    * CPU explicitly indicates not being vulnerable to Meltdown (RDCL_NO):
> NO
> * CPU vulnerability to the three speculative execution attacks variants
>    * Vulnerable to Variant 1:  YES
>    * Vulnerable to Variant 2:  YES
>    * Vulnerable to Variant 3:  NO
> 
> 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
>    * 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:  UNKNOWN  (dmesg truncated, please reboot and
> relaunch this script)
> * Running under Xen PV (64 bits):  UNKNOWN  (dmesg truncated, please
> reboot and relaunch this script)
>> 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
> 
> #######################################################
> 
> I have no idea though if this is due to my hardware, the compiler or the
> kernel. Maybe for the fun of it I'll try to compile 4.15rc9 later with
> that new gcc-7.3 and see what happens.
> 
> Regards
> 
> Michael
> 
> .-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.
> 
> I'm a soldier, not a diplomat.  I can only tell the truth.
> 		-- Kirk, "Errand of Mercy", stardate 3198.9
> 

Tested with upstream vanilla 4.14.15 compiled with current Sid gcc-7.3, 
i get a pass for Spectre v2 (full generic retpoline) and Meltdown 
(a.k.a. "v3").

Spectre v1 is still vulnerable, but that will stay that way for a while.

This is on an Intel Kaby Lake system (my only Intel system at he moment).

PS: apologies for writing the previous message with my feet, it should 
read "4.14.15 kernel" and NOT "4.4.15", and "now" instead of "no"...

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

#191615

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

On 26 January 2018 at 17:18, tv.debian@googlemail.com <
tv.debian@googlemail.com> wrote:

> On 26/01/2018 22:37, Michael Lange wrote:
>
>> On Fri, 26 Jan 2018 22:19:27 +0530
>> "tv.debian@googlemail.com" <tv.debian@googlemail.com> wrote:
>>
>>
>>> gcc-7[.2] was really gcc-7.3-rc for a while, and was doing a good job
>>> at enabling Spectre mitigation (as tested by the
>>> spectre-meltdown-checker and /sys/devices/system/cpu/vulnerabilities/*
>>> entries). No it is really gcc-7.3 and is fully capable.
>>>
>>> I have not tested with a 4.4.15 kernel yet, but that should work too
>>> since most (all?) mitigation have been back-ported by now.
>>>
>>
>> I am definitely anything but an expert on this; but with sid's 4.14.15
>> (which I assumed was compiled with said gcc-7.2) the script here says:
>>
>> ##########################################################
>> Hardware check
>> * Hardware support (CPU microcode) for mitigation techniques
>>    * Indirect Branch Restricted Speculation (IBRS)
>>      * SPEC_CTRL MSR is available:  UNKNOWN  (couldn't
>> read /dev/cpu/0/msr, is msr support enabled in your kernel?)
>>      * CPU indicates IBRS capability:  UNKNOWN  (couldn't
>> read /dev/cpu/0/cpuid, is cpuid support enabled in your kernel?)
>>    * Indirect Branch Prediction Barrier (IBPB)
>>      * PRED_CMD MSR is available:  UNKNOWN  (couldn't read /dev/cpu/0/msr,
>> is msr support enabled in your kernel?)
>>      * CPU indicates IBPB capability:  UNKNOWN  (couldn't
>> read /dev/cpu/0/cpuid, is cpuid support enabled in your kernel?)
>>    * Single Thread Indirect Branch Predictors (STIBP)
>>      * SPEC_CTRL MSR is available:  UNKNOWN  (couldn't
>> read /dev/cpu/0/msr, is msr support enabled in your kernel?)
>>      * CPU indicates STIBP capability:  UNKNOWN  (couldn't
>> read /dev/cpu/0/cpuid, is cpuid support enabled in your kernel?)
>>    * Enhanced IBRS (IBRS_ALL)
>>      * CPU indicates ARCH_CAPABILITIES MSR availability:  UNKNOWN
>> (couldn't read /dev/cpu/0/cpuid, is cpuid support enabled in your kernel?)
>>      * ARCH_CAPABILITIES MSR advertises IBRS_ALL capability:  NO
>>    * CPU explicitly indicates not being vulnerable to Meltdown (RDCL_NO):
>> NO
>> * CPU vulnerability to the three speculative execution attacks variants
>>    * Vulnerable to Variant 1:  YES
>>    * Vulnerable to Variant 2:  YES
>>    * Vulnerable to Variant 3:  NO
>>
>> 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
>>    * 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:  UNKNOWN  (dmesg truncated, please reboot and
>> relaunch this script)
>> * Running under Xen PV (64 bits):  UNKNOWN  (dmesg truncated, please
>> reboot and relaunch this script)
>>
>>> 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
>>
>> #######################################################
>>
>> I have no idea though if this is due to my hardware, the compiler or the
>> kernel. Maybe for the fun of it I'll try to compile 4.15rc9 later with
>> that new gcc-7.3 and see what happens.
>>
>> Regards
>>
>> Michael
>>
>> .-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.
>>
>> I'm a soldier, not a diplomat.  I can only tell the truth.
>>                 -- Kirk, "Errand of Mercy", stardate 3198.9
>>
>>
> Tested with upstream vanilla 4.14.15 compiled with current Sid gcc-7.3, i
> get a pass for Spectre v2 (full generic retpoline) and Meltdown (a.k.a.
> "v3").
>
> Spectre v1 is still vulnerable, but that will stay that way for a while.
>

​Sounds like it believes in your the compiler and it has worked 100%.

Cheers

MF​


>
> This is on an Intel Kaby Lake system (my only Intel system at he moment).
>

​I would buy AMD from now on.

MF​


>
> PS: apologies for writing the previous message with my feet, it should
> read "4.14.15 kernel" and NOT "4.4.15", and "now" instead of "no"...
>
>

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

#191616

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

​Dear All,

I have decided to get rid of GCC8 using ML's helpful command suggestion.

I will install gcc 7 again as sid and try again with kernel 4.14.15.

​Cheers

MF



>

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

#191618

Hi,

On Fri, 26 Jan 2018 22:48:51 +0530
"tv.debian@googlemail.com" <tv.debian@googlemail.com> wrote:

> 
> Tested with upstream vanilla 4.14.15 compiled with current Sid gcc-7.3, 
> i get a pass for Spectre v2 (full generic retpoline) and Meltdown 
> (a.k.a. "v3").
> 
> Spectre v1 is still vulnerable, but that will stay that way for a while.
> 
> This is on an Intel Kaby Lake system (my only Intel system at he
> moment).

Ok, good to know. I'll look later what happens with 4.15.rc9 on my Athlon
machine.

> 
> PS: apologies for writing the previous message with my feet, it should 
> read "4.14.15 kernel" and NOT "4.4.15", and "now" instead of "no"...

No problem, I figured that. Good to see that I am not the only one who
sometimes types with hiss fete :-)

Regards

Michael


.-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.

Actual war is a very messy business.  Very, very messy business.
		-- Kirk, "A Taste of Armageddon", stardate 3193.0

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

#191614

Michael Lange <klappnase@freenet.de> wrote:

> Hardware check
> * Hardware support (CPU microcode) for mitigation techniques
>   * Indirect Branch Restricted Speculation (IBRS)
>     * SPEC_CTRL MSR is available:  UNKNOWN  (couldn't
> read /dev/cpu/0/msr, is msr support enabled in your kernel?)

You forgot to enable MSR support in your kernel, either as module or
compiled in.

S°

-- 
Sigmentation fault. Core dumped.

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

#191624

On Fri, 26 Jan 2018 18:38:23 +0100
Sven Hartge <sven@svenhartge.de> wrote:

> Michael Lange <klappnase@freenet.de> wrote:
> 
> > Hardware check
> > * Hardware support (CPU microcode) for mitigation techniques
> >   * Indirect Branch Restricted Speculation (IBRS)
> >     * SPEC_CTRL MSR is available:  UNKNOWN  (couldn't
> > read /dev/cpu/0/msr, is msr support enabled in your kernel?)
> 
> You forgot to enable MSR support in your kernel, either as module or
> compiled in.

Not me, that's the sid kernel :)

Regards

Michadel

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

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

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

csiph-web