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

[tv.deb...@googlemail.com]

On 27/01/2018 22:47, Michael Lange wrote:

Hi,

On Sat, 27 Jan 2018 22:30:06 +0530
"tv.deb...@googlemail.com"  wrote:


Hi, you need to read the kernel-package doc, it requires configuration.
Read at the minimum /usr/share/doc/kernel-package/README.gz
It contains all the info you need, and even gives you hints as to how
to configure your system, like:

"
  Or, alternately, you could do:
--8<---cut here---start->8---
   cp /usr/share/kernel-package/examples/etc/kernel/postinst.d/initramfs
\ /etc/kernel/postinst.d/
   cp /usr/share/kernel-package/examples/etc/kernel/postrm.d/initramfs \
  /etc/kernel/postrm.d/
--8<---cut here---end--->8---
"

to get a working initrd.


it is certainly a good advice to read the docs before starting.
But then, I admit that I never did and never configured anything for
make-kpkg (besides installing required software of course) and the
resulting kernel packages including the initrd's "just worked".
So I guess that the OP's problem do not result from a misconfigured
kernel-package (unless the OP changed some defaults for the worse) but
from something else. Just a guess of course.

My guess is, that the "make clean" command issued before the last build
attempt failed to clean the source tree properly and the try before was
not succesful either.







Then "make-kpkg clean" may be the answer ?

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

[Michael Lange]

Hi,

On Sat, 27 Jan 2018 22:30:06 +0530
"tv.deb...@googlemail.com"  wrote:

> Hi, you need to read the kernel-package doc, it requires configuration. 
> Read at the minimum /usr/share/doc/kernel-package/README.gz
> It contains all the info you need, and even gives you hints as to how
> to configure your system, like:
> 
> "
>  Or, alternately, you could do:
> --8<---cut here---start->8---
>   cp /usr/share/kernel-package/examples/etc/kernel/postinst.d/initramfs
> \ /etc/kernel/postinst.d/
>   cp /usr/share/kernel-package/examples/etc/kernel/postrm.d/initramfs \
>  /etc/kernel/postrm.d/
> --8<---cut here---end--->8---
> "
> 
> to get a working initrd.

it is certainly a good advice to read the docs before starting.
But then, I admit that I never did and never configured anything for
make-kpkg (besides installing required software of course) and the
resulting kernel packages including the initrd's "just worked".
So I guess that the OP's problem do not result from a misconfigured
kernel-package (unless the OP changed some defaults for the worse) but
from something else. Just a guess of course.

My guess is, that the "make clean" command issued before the last build
attempt failed to clean the source tree properly and the try before was
not succesful either.





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

... bacteriological warfare ... hard to believe we were once foolish
enough to play around with that.
-- McCoy, "The Omega Glory", stardate unknown

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

[tv.deb...@googlemail.com]

On 27/01/2018 20:30, Michael Fothergill wrote:

On 27 January 2018 at 13:38, Michael Lange  wrote:


Hi,

On Sat, 27 Jan 2018 13:12:13 +
Michael Fothergill  wrote:


​I think I will sign up on the gcc gnu help page and ask people if they
have a test case file I can run to 100% confirm the GCC 8 compiler is
running properly.​
​Once I am convinced it is then the next stage is to try to talk to the
developers who maintain the make-kpkg program.


are you still using gcc-8? Here this one didn't work at all for me,
compiling always aborted early with compiler errors. It worked
immediately though after I removed ggc-8 and upgraded gcc-7 to v. 7.3
from sid.

Regards

Michael



​I have sent the kernel-source package maintainer the following email:

**

Dear Sir,

I understand that you are the package maintainer for kernel-source ie
make-kpkg etc. within debian.

I am running debian unstable (Sid)on an amd64 kaveri box.

I installed GCC 8 from the experimental repository.  I am trying to use it
to compile the kernel 4.14.15 using make-kpkg to use the fixes for the
meltdown and spectre vulnerabilities.

The output from doing this is here:

https://pastebin.com/sgrhdCKW

Make-kpkg did not create any linux-image file ..?!

I copied over the config file from/boot and ran make-clean and the
command:  yes "" | make oldconfig before running make-kpkg.

Kernel compilations I do in gentoo (I am a gentoo user as well as a debian
user) usually take a while.

This ran too quickly I think.

Something is not quite right here I think.

It might be that more dependent packages needed to be installed to make
GCC8 run happily.

As a result I have sent an email to the gnu gcc help site (
gcc-h...@gcc.gnu.org) asking them for a test file to check that GCC8 is
running correctly.

But, maybe you might say that make-kpkg needs to be upgraded in some way to
work correctly here and GCC 8 ran OK...


The discussions on these two threads are relevant to this case:

https://lists.debian.org/debian-user/2018/01/msg01159.html

https://lists.debian.org/debian-user/2018/01/msg01002.html

We are all trying to compile kernels that defeat the meltdown and spectre
vulnerabilities.

Comments appreciated.

Regards
​
etc

*

Maybe will end up having to quit with GCC8 but it I am giving it one last
attempt here.

Cheers

MF






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

 "It's hard to believe that something which is neither seen nor
felt can do so much harm."
 "That's true.  But an idea can't be seen or felt.  And that's
what kept the Troglytes in the mines all these centuries.  A mistaken
idea."
 -- Vanna and Kirk, "The Cloud Minders", stardate 5819.0






Hi, you need to read the kernel-package doc, it requires configuration. 
Read at the minimum /usr/share/doc/kernel-package/README.gz
It contains all the info you need, and even gives you hints as to how to 
configure your system, like:


"
Or, alternately, you could do:
--8<---cut here---start->8---
 cp /usr/share/kernel-package/examples/etc/kernel/postinst.d/initramfs \
/etc/kernel/postinst.d/
 cp /usr/share/kernel-package/examples/etc/kernel/postrm.d/initramfs \
/etc/kernel/postrm.d/
--8<---cut here---end--->8---
"

to get a working initrd.

Once it is configured you need a command that will look like:

make-kpkg -j 4 --revision 1 --append_to_version -mykernel --initrd 
kernel_image kernel_headers


to build both kernel and headers packages, and get and initrd to boot 
on. The default is to create the packages one level above the current 
directory (../).


I don't think it is the maintainer to walk you through the procedure, he 
already wrote the docs.


Building on a custom kernel is not very difficult, but it isn't as 
trivial as an "apt-get install", some extra work and care are required. 
And you may void your Debian warranty (you have none anyway) ;-) .

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

[Michael Fothergill]

On 27 January 2018 at 13:38, Michael Lange  wrote:

> Hi,
>
> On Sat, 27 Jan 2018 13:12:13 +
> Michael Fothergill  wrote:
>
> > ​I think I will sign up on the gcc gnu help page and ask people if they
> > have a test case file I can run to 100% confirm the GCC 8 compiler is
> > running properly.​
> > ​Once I am convinced it is then the next stage is to try to talk to the
> > developers who maintain the make-kpkg program.
>
> are you still using gcc-8? Here this one didn't work at all for me,
> compiling always aborted early with compiler errors. It worked
> immediately though after I removed ggc-8 and upgraded gcc-7 to v. 7.3
> from sid.
>
> Regards
>
> Michael
>

​I have sent the kernel-source package maintainer the following email:

**

Dear Sir,

I understand that you are the package maintainer for kernel-source ie
make-kpkg etc. within debian.

I am running debian unstable (Sid)on an amd64 kaveri box.

I installed GCC 8 from the experimental repository.  I am trying to use it
to compile the kernel 4.14.15 using make-kpkg to use the fixes for the
meltdown and spectre vulnerabilities.

The output from doing this is here:

https://pastebin.com/sgrhdCKW

Make-kpkg did not create any linux-image file ..?!

I copied over the config file from/boot and ran make-clean and the
command:  yes "" | make oldconfig before running make-kpkg.

Kernel compilations I do in gentoo (I am a gentoo user as well as a debian
user) usually take a while.

This ran too quickly I think.

Something is not quite right here I think.

It might be that more dependent packages needed to be installed to make
GCC8 run happily.

As a result I have sent an email to the gnu gcc help site (
gcc-h...@gcc.gnu.org) asking them for a test file to check that GCC8 is
running correctly.

But, maybe you might say that make-kpkg needs to be upgraded in some way to
work correctly here and GCC 8 ran OK...


The discussions on these two threads are relevant to this case:

https://lists.debian.org/debian-user/2018/01/msg01159.html

https://lists.debian.org/debian-user/2018/01/msg01002.html

We are all trying to compile kernels that defeat the meltdown and spectre
vulnerabilities.

Comments appreciated.

Regards
​
etc

*

Maybe will end up having to quit with GCC8 but it I am giving it one last
attempt here.

Cheers

MF




>
> .-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.
>
> "It's hard to believe that something which is neither seen nor
> felt can do so much harm."
> "That's true.  But an idea can't be seen or felt.  And that's
> what kept the Troglytes in the mines all these centuries.  A mistaken
> idea."
> -- Vanna and Kirk, "The Cloud Minders", stardate 5819.0
>
>

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

[Michael Fothergill]

On 27 January 2018 at 13:38, Michael Lange  wrote:

> Hi,
>
> On Sat, 27 Jan 2018 13:12:13 +
> Michael Fothergill  wrote:
>
> > ​I think I will sign up on the gcc gnu help page and ask people if they
> > have a test case file I can run to 100% confirm the GCC 8 compiler is
> > running properly.​
> > ​Once I am convinced it is then the next stage is to try to talk to the
> > developers who maintain the make-kpkg program.
>
> are you still using gcc-8? Here this one didn't work at all for me,
> compiling always aborted early with compiler errors. It worked
> immediately though after I removed ggc-8 and upgraded gcc-7 to v. 7.3
> from sid.
>
> Regards
>
>
> Michael
>

​PS The maintainer of  ​
 kernel-package
​ (https://tracker.debian.org/pkg/kernel-package) that contains make-kpkg
is: ​Manoj Srivastava  .

Cheers

MF



> .-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.
>
> "It's hard to believe that something which is neither seen nor
> felt can do so much harm."
> "That's true.  But an idea can't be seen or felt.  And that's
> what kept the Troglytes in the mines all these centuries.  A mistaken
> idea."
> -- Vanna and Kirk, "The Cloud Minders", stardate 5819.0
>
>

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

[Michael Fothergill]

On 27 January 2018 at 13:38, Michael Lange  wrote:

> Hi,
>
> On Sat, 27 Jan 2018 13:12:13 +
> Michael Fothergill  wrote:
>
> > ​I think I will sign up on the gcc gnu help page and ask people if they
> > have a test case file I can run to 100% confirm the GCC 8 compiler is
> > running properly.​
> > ​Once I am convinced it is then the next stage is to try to talk to the
> > developers who maintain the make-kpkg program.
>
> are you still using gcc-8? Here this one didn't work at all for me,
> compiling always aborted early with compiler errors. It worked
> immediately though after I removed ggc-8 and upgraded gcc-7 to v. 7.3
> from sid.
>

​In my case after I took you helpful advice and installed libelf-dev in GCC
8 (which I am still using)  the crash I had went away.
​
I think now GCC 8 is close to working OK.

Perhaps it needs another little nudge or some other package we don't know
about.

I have sent the gnu gcc help people the following email:

**

Dear All,

I am running debian unstable on an amd64 kaveri box.

I recently installed GCC 8 from the Debian experimental site:

https://packages.debian.org/experimental/devel/gcc-8

I also installed libelf-dev.

It did run correctly without it.

I have been using it to try to compile and install linux kernel 4.14.15
using the
debian package make-kpkg.

The output from doing this is here:

https://pastebin.com/sgrhdCKW

I copied over the config file from/boot and ran make-clean and the
command:  yes "" | make oldconfig before running make-kpkg.

Kernel compilations I do in gentoo usually take a while.

This ran too quickly I think.

Something is not quite right here.

Perhaps some more depedent packages needed to be installed to make GCC8 run
happily.

Do you have a test file I can compile that will check whether GCC 8 is
really running correctly?

The discussions on these two threads are relevant:

https://lists.debian.org/debian-user/2018/01/msg01159.html

https://lists.debian.org/debian-user/2018/01/msg01002.html

We are all trying to compile kernels that defeat the meltdown and spectre
vulnerabilities.

Comments appreciated.

Regards

​MF​



Maybe they can help here.

Cheers

MF



>
> Regards
>
> Michael
>
> .-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.
>
> "It's hard to believe that something which is neither seen nor
> felt can do so much harm."
> "That's true.  But an idea can't be seen or felt.  And that's
> what kept the Troglytes in the mines all these centuries.  A mistaken
> idea."
> -- Vanna and Kirk, "The Cloud Minders", stardate 5819.0
>
>

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

[Michael Fothergill]

On 27 January 2018 at 13:17, Michael Lange  wrote:

> On Sat, 27 Jan 2018 12:32:24 +
> Michael Fothergill  wrote:
>
> > On 27 January 2018 at 11:59, Michael Lange  wrote:
> >
> > > Hi,
> > >
> > > On Sat, 27 Jan 2018 11:26:25 +
> > > Michael Fothergill  wrote:
> > >
> > > >
> > > > Where would the default location of such a file be if were created
> > > > using the make-kpkg command?
> > >
> > > the package should be in the source's parent directory, in your case I
> > > guess in /usr/src .
> > >
> >
> > ​I think something is not right here. The compilation was very quick.
> > Normally in gentoo the kernel compilation takes a little while.
> > Maybe something got left out.
> >
> > Maybe I should have run mrproper after make clean before running
> > make-kpkg.
>
> Yes, I naturally cannot tell from here, but it sounds like for some
> reason the procedure was terminated prematurely.
>

​But, you would argue that what terminated was the make-kpkg efforts to
make use of the result of the successful compilation not a malfunction of
the compiler itself

At least I think that is what you are saying/suggesting here.

It did occur to me that maybe I still need some extra package to be
installed either for the compiler or make-kpkg here.

Cheers

MF​



>
> Regards
>
> Michael
>
>
> .-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.
>
> It is necessary to have purpose.
> -- Alice #1, "I, Mudd", stardate 4513.3
>
>

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

[Michael Lange]

Hi,

On Sat, 27 Jan 2018 13:12:13 +
Michael Fothergill  wrote:

> ​I think I will sign up on the gcc gnu help page and ask people if they
> have a test case file I can run to 100% confirm the GCC 8 compiler is
> running properly.​
> ​Once I am convinced it is then the next stage is to try to talk to the
> developers who maintain the make-kpkg program.

are you still using gcc-8? Here this one didn't work at all for me,
compiling always aborted early with compiler errors. It worked
immediately though after I removed ggc-8 and upgraded gcc-7 to v. 7.3
from sid.

Regards

Michael

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

"It's hard to believe that something which is neither seen nor
felt can do so much harm."
"That's true.  But an idea can't be seen or felt.  And that's
what kept the Troglytes in the mines all these centuries.  A mistaken
idea."
-- Vanna and Kirk, "The Cloud Minders", stardate 5819.0

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

[Michael Fothergill]

On 27 January 2018 at 12:43, Michael Lange  wrote:

> Hi,
>
> On Sat, 27 Jan 2018 12:12:57 +
> Michael Fothergill  wrote:
>
> >
> > ​Should the filename be something like linux-image-4.14.14.deb etc?
>
> With default settings for make-kpkg the filename is probably a little
> longer, here it looks like
>
> linux-image-4.15.0-rc9-klappnase270118_4.15.0-rc9-
> klappnase270118-10.00.Custom_amd64.deb
>
>
> >
> > Maybe Greg could think some find command that would search everywhere in
> > the install I have here and then find it in some funny directory (even
> > /tmp?) no one has ever heard of.
> >
> > I would be grateful for suggestions here.
> >
> > Could there be a bug in gcc 8 that made it forget to actually output the
> > file?
>
> I don't think that gcc is to blame.


​I think I will sign up on the gcc gnu help page and ask people if they
have a test case file I can run to 100% confirm the GCC 8 compiler is
running properly.​
​Once I am convinced it is then the next stage is to try to talk to the
developers who maintain the make-kpkg program.

Cheers

MF​




> Did you look at the final messages
> make-kpkg printed? If run successfully it should say something like
> "building package linux-image-..." .
>
> Regards
>
> Michael
>

​​



>
>
> .-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.
>
> Power is danger.
> -- The Centurion, "Balance of Terror", stardate 1709.2
>
>

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

[Michael Lange]

On Sat, 27 Jan 2018 12:32:24 +
Michael Fothergill  wrote:

> On 27 January 2018 at 11:59, Michael Lange  wrote:
> 
> > Hi,
> >
> > On Sat, 27 Jan 2018 11:26:25 +
> > Michael Fothergill  wrote:
> >
> > >
> > > Where would the default location of such a file be if were created
> > > using the make-kpkg command?
> >
> > the package should be in the source's parent directory, in your case I
> > guess in /usr/src .
> >
> 
> ​I think something is not right here. The compilation was very quick.
> Normally in gentoo the kernel compilation takes a little while.
> Maybe something got left out.
> 
> Maybe I should have run mrproper after make clean before running
> make-kpkg.

Yes, I naturally cannot tell from here, but it sounds like for some
reason the procedure was terminated prematurely.

Regards

Michael


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

It is necessary to have purpose.
-- Alice #1, "I, Mudd", stardate 4513.3

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

[Michael Fothergill]

It does seem as if make-kpkg has gone awol here.

MF

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

[Michael Fothergill]

On 27 January 2018 at 12:43, Michael Lange  wrote:

> Hi,
>
> On Sat, 27 Jan 2018 12:12:57 +
> Michael Fothergill  wrote:
>
> >
> > ​Should the filename be something like linux-image-4.14.14.deb etc?
>
> With default settings for make-kpkg the filename is probably a little
> longer, here it looks like
>
> linux-image-4.15.0-rc9-klappnase270118_4.15.0-rc9-
> klappnase270118-10.00.Custom_amd64.deb
>
>
> >
> > Maybe Greg could think some find command that would search everywhere in
> > the install I have here and then find it in some funny directory (even
> > /tmp?) no one has ever heard of.
> >
> > I would be grateful for suggestions here.
> >
> > Could there be a bug in gcc 8 that made it forget to actually output the
> > file?
>
> I don't think that gcc is to blame. Did you look at the final messages
> make-kpkg printed? If run successfully it should say something like
> "building package linux-image-..." .
>

​It never did it.   It did this at the end:​


chmod 0644 debian/control debian/changelog
make -f debian/rules debian/stamp/conf/kernel-conf
make[2]: Entering directory '/usr/src/linux-4.14.15'
make[2]: 'debian/stamp/conf/kernel-conf' is up to date.
make[2]: Leaving directory '/usr/src/linux-4.14.15'
make[1]: Leaving directory '/usr/src/linux-4.14.15'
echo done > debian/stamp/conf/minimal_debian
exec debian/rules
nothing to be done.

​and stopped.

if you look through the rest of the output I posted above its not there
AFAICT.

Cheers

MF​



> Regards
>
> Michael
>
>
> .-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.
>
> Power is danger.
> -- The Centurion, "Balance of Terror", stardate 1709.2
>
>

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

[Michael Fothergill]

On 27 January 2018 at 11:59, Michael Lange  wrote:

> Hi,
>
> On Sat, 27 Jan 2018 11:26:25 +
> Michael Fothergill  wrote:
>
> >
> > Where would the default location of such a file be if were created using
> > the make-kpkg command?
>
> the package should be in the source's parent directory, in your case I
> guess in /usr/src .
>

​I think something is not right here. The compilation was very quick.
Normally in gentoo the kernel compilation takes a little while.
Maybe something got left out.

Maybe I should have run mrproper after make clean before running make-kpkg.

Cheers

MF​


>
> Regards
>
> Michael
>
>
> .-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.
>
> Vulcans never bluff.
> -- Spock, "The Doomsday Machine", stardate 4202.1
>
>

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

[Michael Lange]

Hi,

On Sat, 27 Jan 2018 12:12:57 +
Michael Fothergill  wrote:

> 
> ​Should the filename be something like linux-image-4.14.14.deb etc?

With default settings for make-kpkg the filename is probably a little
longer, here it looks like

linux-image-4.15.0-rc9-klappnase270118_4.15.0-rc9-klappnase270118-10.00.Custom_amd64.deb


> 
> Maybe Greg could think some find command that would search everywhere in
> the install I have here and then find it in some funny directory (even
> /tmp?) no one has ever heard of.
> 
> I would be grateful for suggestions here.
> 
> Could there be a bug in gcc 8 that made it forget to actually output the
> file?

I don't think that gcc is to blame. Did you look at the final messages
make-kpkg printed? If run successfully it should say something like
"building package linux-image-..." .

Regards

Michael


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

Power is danger.
-- The Centurion, "Balance of Terror", stardate 1709.2

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

[Michael Fothergill]

On 27 January 2018 at 12:12, Michael Fothergill <
michael.fotherg...@gmail.com> wrote:

>
>
> On 27 January 2018 at 11:59, Michael Lange  wrote:
>
>> Hi,
>>
>> On Sat, 27 Jan 2018 11:26:25 +
>> Michael Fothergill  wrote:
>>
>> >
>> > Where would the default location of such a file be if were created using
>> > the make-kpkg command?
>>
>> the package should be in the source's parent directory, in your case I
>> guess in /usr/src .
>>
>
> ​Many thanks for the help again here.  I can't see it in /usr/src:​
>
>
> root@mikef-PC:/usr/src# ls -l
> total 907316
> drwxrwxr-x 26 root  root   4096 Jan 27 11:01 linux-4.14.15
> -rw-r--r--  1 mikef mikef 825139200 Jan 25 16:43 linux-4.14.15.tar
> drwxr-xr-x  2 root  root   4096 Jan 25 18:02 linux-config-4.14
> drwxr-xr-x  4 root  root   4096 Jan 25 00:01
> linux-headers-4.14.0-3-amd64
> drwxr-xr-x  4 root  root   4096 Jan 25 00:01
> linux-headers-4.14.0-3-common
> drwxr-xr-x  4 root  root   4096 Jan 24 16:32
> linux-headers-4.9.0-4-amd64
> drwxr-xr-x  4 root  root   4096 Jan 24 16:33
> linux-headers-4.9.0-4-common
> lrwxrwxrwx  1 root  root 24 Jan 14 19:45 linux-kbuild-4.14 ->
> ../lib/linux-kbuild-4.14
> lrwxrwxrwx  1 root  root 24 Jan 15 04:43 linux-kbuild-4.15 ->
> ../lib/linux-kbuild-4.15
> lrwxrwxrwx  1 root  root 23 Aug  6 05:24 linux-kbuild-4.9 ->
> ../lib/linux-kbuild-4.9
> -rw-r--r--  1 root  root 216052 Jan 14 19:45
> linux-patch-4.14-rt.patch.xz
> -rw-r--r--  1 root  root  103701828 Jan 14 19:45 linux-source-4.14.tar.xz
> drwxr-xr-x  8 root  root   4096 Nov 18 09:15 open-vm-tools-10.1.5
> root@mikef-PC:/usr/src#
>
>
> ​Should the filename be something like linux-image-4.14.14.deb etc?
>
> Maybe Greg could think some find command that would search everywhere in
> the install I have here and then find it in some funny directory (even
> /tmp?) no one has ever heard of.
>
> I would be grateful for suggestions here.
>
> Could there be a bug in gcc 8 that made it forget to actually output the
> file?
>
> Thanks
>
> MF​
>

​Available space for the file creation does not seem to be a problem:

​
 root@mikef-PC:/usr/src# df
Filesystem 1K-blocks Used Available Use% Mounted on
udev 35157160   3515716   0% /dev
tmpfs 71418017564696616   3% /run
/dev/sda9  352522356 17476768 317115400   6% /
tmpfs357088488304   3482580   3% /dev/shm
tmpfs   51204  5116   1% /run/lock
tmpfs35708840   3570884   0% /sys/fs/cgroup
tmpfs 714176   12714164   1% /run/user/1000
root@mikef-PC:/usr/src#

​MF​



>
>
>
>>
>> Regards
>>
>> Michael
>>
>>
>> .-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.
>>
>> Vulcans never bluff.
>> -- Spock, "The Doomsday Machine", stardate 4202.1
>>
>>
>

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

[Michael Fothergill]

On 27 January 2018 at 11:59, Michael Lange  wrote:

> Hi,
>
> On Sat, 27 Jan 2018 11:26:25 +
> Michael Fothergill  wrote:
>
> >
> > Where would the default location of such a file be if were created using
> > the make-kpkg command?
>
> the package should be in the source's parent directory, in your case I
> guess in /usr/src .
>

​Many thanks for the help again here.  I can't see it in /usr/src:​


root@mikef-PC:/usr/src# ls -l
total 907316
drwxrwxr-x 26 root  root   4096 Jan 27 11:01 linux-4.14.15
-rw-r--r--  1 mikef mikef 825139200 Jan 25 16:43 linux-4.14.15.tar
drwxr-xr-x  2 root  root   4096 Jan 25 18:02 linux-config-4.14
drwxr-xr-x  4 root  root   4096 Jan 25 00:01
linux-headers-4.14.0-3-amd64
drwxr-xr-x  4 root  root   4096 Jan 25 00:01
linux-headers-4.14.0-3-common
drwxr-xr-x  4 root  root   4096 Jan 24 16:32 linux-headers-4.9.0-4-amd64
drwxr-xr-x  4 root  root   4096 Jan 24 16:33
linux-headers-4.9.0-4-common
lrwxrwxrwx  1 root  root 24 Jan 14 19:45 linux-kbuild-4.14 ->
../lib/linux-kbuild-4.14
lrwxrwxrwx  1 root  root 24 Jan 15 04:43 linux-kbuild-4.15 ->
../lib/linux-kbuild-4.15
lrwxrwxrwx  1 root  root 23 Aug  6 05:24 linux-kbuild-4.9 ->
../lib/linux-kbuild-4.9
-rw-r--r--  1 root  root 216052 Jan 14 19:45
linux-patch-4.14-rt.patch.xz
-rw-r--r--  1 root  root  103701828 Jan 14 19:45 linux-source-4.14.tar.xz
drwxr-xr-x  8 root  root   4096 Nov 18 09:15 open-vm-tools-10.1.5
root@mikef-PC:/usr/src#


​Should the filename be something like linux-image-4.14.14.deb etc?

Maybe Greg could think some find command that would search everywhere in
the install I have here and then find it in some funny directory (even
/tmp?) no one has ever heard of.

I would be grateful for suggestions here.

Could there be a bug in gcc 8 that made it forget to actually output the
file?

Thanks

MF​




>
> Regards
>
> Michael
>
>
> .-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.
>
> Vulcans never bluff.
> -- Spock, "The Doomsday Machine", stardate 4202.1
>
>

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

[Michael Fothergill]

On 27 January 2018 at 11:26, Michael Fothergill <
michael.fotherg...@gmail.com> wrote:

> When you install the kernel, the following page (
> https://www.debian.org/releases/jessie/i386/ch08s06.html.en) says you
> must run the following command:
>
> *​dpkg -i ../linux-image-3.16-subarchitecture_1.0.custom_i386.deb*.
>
> ​Do I need to run mrproper beforehand?
>
> I can't see any linux-image file in the /usr/src/4.14.15 directory:
>
> ​root@mikef-PC:/usr/src/linux-4.14.15# ls -l
> total 724
> drwxrwxr-x  32 root root   4096 Jan 23 18:58 arch
> drwxrwxr-x   3 root root   4096 Jan 23 18:58 block
> drwxrwxr-x   2 root root   4096 Jan 23 18:58 certs
> -rw-rw-r--   1 root root  18693 Jan 23 18:58 COPYING
> -rw-rw-r--   1 root root  98556 Jan 23 18:58 CREDITS
> drwxrwxr-x   4 root root   4096 Jan 23 18:58 crypto
> drwxr-xr-x  10 root root   4096 Jan 27 11:00 debian
> drwxrwxr-x 121 root root  12288 Jan 23 18:58 Documentation
> drwxrwxr-x 131 root root   4096 Jan 23 18:58 drivers
> drwxrwxr-x   2 root root   4096 Jan 23 18:58 firmware
> drwxrwxr-x  74 root root   4096 Jan 23 18:58 fs
> drwxrwxr-x  29 root root   4096 Jan 25 21:13 include
> drwxrwxr-x   2 root root   4096 Jan 23 18:58 init
> drwxrwxr-x   2 root root   4096 Jan 23 18:58 ipc
> -rw-rw-r--   1 root root   2293 Jan 23 18:58 Kbuild
> -rw-rw-r--   1 root root287 Jan 23 18:58 Kconfig
> drwxrwxr-x  17 root root   4096 Jan 27 11:00 kernel
> drwxrwxr-x  13 root root  12288 Jan 23 18:58 lib
> -rw-rw-r--   1 root root 430471 Jan 23 18:58 MAINTAINERS
> -rw-rw-r--   1 root root  59978 Jan 23 18:58 Makefile
> drwxrwxr-x   3 root root   4096 Jan 23 18:58 mm
> drwxrwxr-x  69 root root   4096 Jan 23 18:58 net
> -rw-rw-r--   1 root root722 Jan 23 18:58 README
> drwxrwxr-x  28 root root   4096 Jan 23 18:58 samples
> drwxrwxr-x  14 root root   4096 Jan 23 18:58 scripts
> drwxrwxr-x  10 root root   4096 Jan 23 18:58 security
> drwxrwxr-x  24 root root   4096 Jan 23 18:58 sound
> drwxrwxr-x  30 root root   4096 Jan 23 18:58 tools
> drwxrwxr-x   2 root root   4096 Jan 23 18:58 usr
> drwxrwxr-x   4 root root   4096 Jan 23 18:58 virt
> root@mikef-PC:/usr/src/linux-4.14.15#
>
> Where would the default location of such a file be if were created using
> the make-kpkg command?
>
> Cheers
>


> MF
>
>
​PS since I can't seem to find the linux-image file for the new kernel to
run dpkg -i on
should I have run the ​





*fakeroot make-kpkg --initrd --revision=1.0.custom kernel_imag​e ie
fakeroot make-kpkg --initrd --revision=4.14.15.krankenhaus kernel_imag​e *
​command instead of just make-kpkg to create it?

Cheers





​

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

[Michael Lange]

Hi,

On Sat, 27 Jan 2018 11:26:25 +
Michael Fothergill  wrote:

> 
> Where would the default location of such a file be if were created using
> the make-kpkg command?

the package should be in the source's parent directory, in your case I
guess in /usr/src .

Regards

Michael


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

Vulcans never bluff.
-- Spock, "The Doomsday Machine", stardate 4202.1

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

[Michael Fothergill]

When you install the kernel, the following page (
https://www.debian.org/releases/jessie/i386/ch08s06.html.en) says you must
run the following command:

*​dpkg -i ../linux-image-3.16-subarchitecture_1.0.custom_i386.deb*.

​Do I need to run mrproper beforehand?

I can't see any linux-image file in the /usr/src/4.14.15 directory:

​root@mikef-PC:/usr/src/linux-4.14.15# ls -l
total 724
drwxrwxr-x  32 root root   4096 Jan 23 18:58 arch
drwxrwxr-x   3 root root   4096 Jan 23 18:58 block
drwxrwxr-x   2 root root   4096 Jan 23 18:58 certs
-rw-rw-r--   1 root root  18693 Jan 23 18:58 COPYING
-rw-rw-r--   1 root root  98556 Jan 23 18:58 CREDITS
drwxrwxr-x   4 root root   4096 Jan 23 18:58 crypto
drwxr-xr-x  10 root root   4096 Jan 27 11:00 debian
drwxrwxr-x 121 root root  12288 Jan 23 18:58 Documentation
drwxrwxr-x 131 root root   4096 Jan 23 18:58 drivers
drwxrwxr-x   2 root root   4096 Jan 23 18:58 firmware
drwxrwxr-x  74 root root   4096 Jan 23 18:58 fs
drwxrwxr-x  29 root root   4096 Jan 25 21:13 include
drwxrwxr-x   2 root root   4096 Jan 23 18:58 init
drwxrwxr-x   2 root root   4096 Jan 23 18:58 ipc
-rw-rw-r--   1 root root   2293 Jan 23 18:58 Kbuild
-rw-rw-r--   1 root root287 Jan 23 18:58 Kconfig
drwxrwxr-x  17 root root   4096 Jan 27 11:00 kernel
drwxrwxr-x  13 root root  12288 Jan 23 18:58 lib
-rw-rw-r--   1 root root 430471 Jan 23 18:58 MAINTAINERS
-rw-rw-r--   1 root root  59978 Jan 23 18:58 Makefile
drwxrwxr-x   3 root root   4096 Jan 23 18:58 mm
drwxrwxr-x  69 root root   4096 Jan 23 18:58 net
-rw-rw-r--   1 root root722 Jan 23 18:58 README
drwxrwxr-x  28 root root   4096 Jan 23 18:58 samples
drwxrwxr-x  14 root root   4096 Jan 23 18:58 scripts
drwxrwxr-x  10 root root   4096 Jan 23 18:58 security
drwxrwxr-x  24 root root   4096 Jan 23 18:58 sound
drwxrwxr-x  30 root root   4096 Jan 23 18:58 tools
drwxrwxr-x   2 root root   4096 Jan 23 18:58 usr
drwxrwxr-x   4 root root   4096 Jan 23 18:58 virt
root@mikef-PC:/usr/src/linux-4.14.15#

Where would the default location of such a file be if were created using
the make-kpkg command?

Cheers

MF

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

[Michael Fothergill]

On 25 January 2018 at 23:28, Michael Lange  wrote:

> Hi,
>
> On Thu, 25 Jan 2018 22:23:38 +
> Michael Fothergill  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 :-)
>

​I installed libelf-dev and did make clean.  Then I copied over the config
file and did you "Alas poor Yorick" Yes""|oldconfig
command followed by make.kpkg again and I think it worked:

 ​root@mikef-PC:/usr/src/linux-4.14.15# !498
make-kpkg
exec make kpkg_version=13.018+nmu1 -f /usr/share/kernel-package/ruleset/
minimal.mk debian
== making target debian/stamp/conf/minimal_debian [new prereqs: ]==
This is kernel package version 13.018+nmu1.
test -d debian || mkdir debian
test ! -e stamp-building || rm -f stamp-building
install -p -m 755 /usr/share/kernel-package/rules debian/rules
for file in ChangeLog  Control  Control.bin86 config templates.in rules;
do  \
cp -f  /usr/share/kernel-package/$file
./debian/;   \
done
cp: cannot stat '/usr/share/kernel-package/ChangeLog': No such file or
directory
for dir  in Config docs examples ruleset scripts pkg po;
do  \
  cp -af /usr/share/kernel-package/$dir
./debian/; \
done
test -f debian/control || sed -e 's/=V/4.14.15/g'  \
-e 's/=D/4.14.15-10.00.Custom/g' -e 's/=A/amd64/g'
\
-e 's/=SA//g'  \
-e 's/=I//g'\
-e 's/=CV/4.14/g'\
-e 's/=M/Unknown Kernel Package Maintainer
/g'\
-e 's/=ST/linux/g'  -e 's/=B/x86_64/g'\
-e 's/=R//g'/usr/share/kernel-package/Control >
debian/control
test -f debian/changelog ||  sed -e 's/=V/4.14.15/g'   \
-e 's/=D/4.14.15-10.00.Custom/g'-e 's/=A/amd64/g'
\
-e 's/=ST/linux/g' -e 's/=B/x86_64/g' \
-e 's/=M/Unknown Kernel Package Maintainer
/g'
\
 /usr/share/kernel-package/changelog > debian/changelog
chmod 0644 debian/control debian/changelog
test -d ./debian/stamp || mkdir debian/stamp
make -f debian/rules debian/stamp/conf/kernel-conf
make[1]: Entering directory '/usr/src/linux-4.14.15'
== making target debian/stamp/conf/kernel-conf [new prereqs: ]==
makeARCH=x86_64 \
oldconfig;
make[2]: Entering directory '/usr/src/linux-4.14.15'
scripts/kconfig/conf  --oldconfig Kconfig
#
# configuration written to .config
#
make[2]: Leaving directory '/usr/src/linux-4.14.15'
makeARCH=x86_64 prepare
make[2]: Entering directory '/usr/src/linux-4.14.15'
scripts/kconfig/conf  --silentoldconfig Kconfig
  SYSTBL  arch/x86/include/generated/asm/syscalls_32.h
  SYSHDR  arch/x86/include/generated/asm/unistd_32_ia32.h
  SYSHDR  arch/x86/include/generated/asm/unistd_64_x32.h
  SYSTBL  arch/x86/include/generated/asm/syscalls_64.h
  HYPERCALLS arch/x86/include/generated/asm/xen-hypercalls.h
  SYSHDR  arch/x86/include/generated/uapi/asm/unistd_32.h
  SYSHDR  arch/x86/include/generated/uapi/asm/unistd_64.h
  SYSHDR  arch/x86/include/generated/uapi/asm/unistd_x32.h
  HOSTCC  arch/x86/tools/relocs_32.o
  HOSTCC  arch/x86/tools/relocs_64.o
  HOSTCC  arch/x86/tools/relocs_common.o
  HOSTLD  arch/x86/tools/relocs
  CHK include/config/kernel.release
  UPD include/config/kernel.release
  WRAParch/x86/include/generated/asm/clkdev.h
  WRAParch/x86/include/generated/asm/dma-contiguous.h
  WRAParch/x86/include/generated/asm/early_ioremap.h
  WRAParch/x86/include/generated/asm/mcs_spinlock.h
  WRAParch/x86/include/generated/asm/mm-arch-hooks.h
  CHK include/generated/uapi/linux/version.h
  UPD include/generated/uapi/linux/version.h
  CHK include/generated/utsrelease.h
  UPD include/generated/utsrelease.h
  CC  arch/x86/purgatory/purgatory.o
  AS  arch/x86/purgatory/stack.o
  AS  arch/x86/purgatory/setup-x86_64.o
  CC  arch/x86/purgatory/sha256.o
  AS  arch/x86/purgatory/entry64.o
  CC  arch/x86/purgatory/string.o
  LD  arch/x86/purgatory/purgatory.ro
  BIN2C   

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

[Michael Fothergill]

On 26 January 2018 at 22:59, Michael Lange  wrote:

> On Fri, 26 Jan 2018 23:41:07 +0100
> Michael Lange  wrote:
>
> > When I check /proc/cpuinfo I see that "msr" is listed in the "flags"
> > section. So why doesn't the driver load automagically?
> > But then, at least with the version of the checker-script here, it
> > doesn't seem to make any difference, at least for whatever the script
> > tries.
> > Don't know if enabling msr will do me any good otherwise.
>
> Update:
> just checked with my laptop (Intel/Baytrail); it is the same with msr,
> module not loaded automatically, when loaded manually the contents
> of /dev/cpu/0 look just as on my AMD desktop machine. The output of the
> checker script still says "No" in the lines referring to msr.
> *BUT*, since I finally managed to compile 4.15.rc9 with gcc-7.3, the
> script claims the laptop is no longer vulnerable to "Spectre2".
> I think I'll count that as success and call it a night now :-)
>

​You could run this command:​


​djt /home/mikef # !424
grep . /sys/devices/system/cpu/vulnerabilities/*
/sys/devices/system/cpu/vulnerabilities/meltdown:Not affected
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Vulnerable
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Vulnerable: Minimal AMD
ASM retpoline


or use the checker (I assume you already are)

https://github.com/speed47/spectre-meltdown-checker

Cheers

MF




​


>
> Best regards
>
> Michael
>
>
> .-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.
>
> I realize that command does have its fascination, even under
> circumstances such as these, but I neither enjoy the idea of command
> nor am I frightened of it.  It simply exists, and I will do whatever
> logically needs to be done.
> -- Spock, "The Galileo Seven", stardate 2812.7
>
>

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

[Michael Lange]

On Fri, 26 Jan 2018 23:49:46 +0100
Sven Hartge  wrote:

> Michael Lange  wrote:
> 
> > When I check /proc/cpuinfo I see that "msr" is listed in the "flags"
> > section. So why doesn't the driver load automagically?
> 
> It is not programmed to load automatically, because writing to MSRs is
> dangerous and can even damage your computer or CPU. In any normal
> operation you don't need this code loaded and active, only when you try
> to do special things with your CPU it is needed, as in this case.
> 
> > But then, at least with the version of the checker-script here, it
> > doesn't seem to make any difference, at least for whatever the script
> > tries.  Don't know if enabling msr will do me any good otherwise.
> 
> The script loads itself when run as root. It then reads the neccessary
> information from /dev/cpu/*/msr and unloads the module when done. You
> don't want or even need to load the module manually.

Ok, then I figure my systems to be ok msr-wise :)

I don't know, but I guess there may be different "levels" or
"capabilities" (or whatever this is called) of msr, since the contents
of /dev/cpu/0 look different from that of your machine and the script
still says "no" to the msr-related checks here. Since it's the same with
the official kernels I guess I can (and have to) live with it.

Gruss

Michael

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

Yes, it is written.  Good shall always destroy evil.
-- Sirah the Yang, "The Omega Glory", stardate unknown

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

[Michael Lange]

On Fri, 26 Jan 2018 23:41:07 +0100
Michael Lange  wrote:
 
> When I check /proc/cpuinfo I see that "msr" is listed in the "flags"
> section. So why doesn't the driver load automagically?
> But then, at least with the version of the checker-script here, it
> doesn't seem to make any difference, at least for whatever the script
> tries.
> Don't know if enabling msr will do me any good otherwise.

Update:
just checked with my laptop (Intel/Baytrail); it is the same with msr,
module not loaded automatically, when loaded manually the contents
of /dev/cpu/0 look just as on my AMD desktop machine. The output of the
checker script still says "No" in the lines referring to msr. 
*BUT*, since I finally managed to compile 4.15.rc9 with gcc-7.3, the
script claims the laptop is no longer vulnerable to "Spectre2".
I think I'll count that as success and call it a night now :-)

Best regards

Michael


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

I realize that command does have its fascination, even under
circumstances such as these, but I neither enjoy the idea of command
nor am I frightened of it.  It simply exists, and I will do whatever
logically needs to be done.
-- Spock, "The Galileo Seven", stardate 2812.7

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

[Sven Hartge]

Michael Lange  wrote:

> When I check /proc/cpuinfo I see that "msr" is listed in the "flags"
> section. So why doesn't the driver load automagically?

It is not programmed to load automatically, because writing to MSRs is
dangerous and can even damage your computer or CPU. In any normal
operation you don't need this code loaded and active, only when you try
to do special things with your CPU it is needed, as in this case.

> But then, at least with the version of the checker-script here, it
> doesn't seem to make any difference, at least for whatever the script
> tries.  Don't know if enabling msr will do me any good otherwise.

The script loads itself when run as root. It then reads the neccessary
information from /dev/cpu/*/msr and unloads the module when done. You
don't want or even need to load the module manually.

S°

-- 
Sigmentation fault. Core dumped.

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

[Michael Lange]

On Fri, 26 Jan 2018 12:45:13 -0500
Greg Wooledge  wrote:

> On Fri, Jan 26, 2018 at 06:07:13PM +0100, Michael Lange wrote:
> > 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:
> 
> You shouldn't have to assume.  /proc/version tells you which compiler
> was used.
> 
> wooledg:~$ cat /proc/version
> Linux version 4.9.0-5-amd64 (debian-ker...@lists.debian.org) (gcc
> version 6.3.0 20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.9.65-3
> +deb9u2 (2018-01-04)

Oh, thanks, didn't know that one yet ;)

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

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

[Michael Lange]

On Fri, 26 Jan 2018 23:25:55 +0100
Sven Hartge  wrote:

> Do the contents of the /dev/cpu directory change between loaded and
> unloaded msr.ko?
> 
> When msr.ko is loaded, there should be directory for each CPU in the
> system:
> 
> # ls -ld /dev/cpu/*
> drwxr-xr-x 2 root root  80 Jan 26 23:23 /dev/cpu/0
> drwxr-xr-x 2 root root  80 Jan 26 23:23 /dev/cpu/1
> drwxr-xr-x 2 root root  80 Jan 26 23:23 /dev/cpu/2
> drwxr-xr-x 2 root root  80 Jan 26 23:23 /dev/cpu/3
> crw--- 1 root root 10, 184 Jan 15 23:06 /dev/cpu/microcode
> 
> # ls -l /dev/cpu/0
> total 0
> crw--- 1 root root 203, 0 Jan 22 19:32 cpuid
> crw--- 1 root root 202, 0 Jan 26 23:23 msr

Actually yes, here it looks (when I load msr) like:

# ls -l /dev/cpu/0
insgesamt 0
crw--- 1 root root 202, 0 Jan 26 23:33 msr

When I check /proc/cpuinfo I see that "msr" is listed in the "flags"
section. So why doesn't the driver load automagically?
But then, at least with the version of the checker-script here, it
doesn't seem to make any difference, at least for whatever the script
tries.
Don't know if enabling msr will do me any good otherwise.

Regards

Michael


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

The joys of love made her human and the agonies of love destroyed her.
-- Spock, "Requiem for Methuselah", stardate 5842.8

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

[Sven Hartge]

Michael Lange  wrote:

> Yes, it is the sid kernel, and the module exists. When running the
> script as root it is the same. lsmod shows that the msr module is not
> loaded. If I load it manually with modprobe it appears to load without
> errors, but the output of the checker-script does not change.

Do the contents of the /dev/cpu directory change between loaded and
unloaded msr.ko?

When msr.ko is loaded, there should be directory for each CPU in the
system:

# ls -ld /dev/cpu/*
drwxr-xr-x 2 root root  80 Jan 26 23:23 /dev/cpu/0
drwxr-xr-x 2 root root  80 Jan 26 23:23 /dev/cpu/1
drwxr-xr-x 2 root root  80 Jan 26 23:23 /dev/cpu/2
drwxr-xr-x 2 root root  80 Jan 26 23:23 /dev/cpu/3
crw--- 1 root root 10, 184 Jan 15 23:06 /dev/cpu/microcode

# ls -l /dev/cpu/0
total 0
crw--- 1 root root 203, 0 Jan 22 19:32 cpuid
crw--- 1 root root 202, 0 Jan 26 23:23 msr


> I admit I don't know anything about msr, is this possibly an Intel
> specific thing?

While Intel introduced the concept of MSRs, they are not limited to
Intel CPUs.

S°

-- 
Sigmentation fault. Core dumped.

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

[Michael Lange]

On Fri, 26 Jan 2018 21:28:19 +0100
Sven Hartge  wrote:

> > Not me, that's the sid kernel :)
> 
> No. The kernel from Sid has support for MSR as module:
> 
> root@host:~# modinfo msr
> filename: /lib/modules/4.14.0-3-amd64/kernel/arch/x86/kernel/msr.ko
> license:GPL
> description:x86 generic MSR driver
> author: H. Peter Anvin 
> depends:
> intree: Y
> name:   msr
> vermagic:   4.14.0-3-amd64 SMP mod_unload modversions 
> 
> Did you run the script as user or as root?
> 
> I get the same errors as you if I don't run the script as root. For the
> checks to be reliable, *including* the dmesg-check, you need to run the
> script as root.

Yes, it is the sid kernel, and the module exists. When running the script
as root it is the same. lsmod shows that the msr module is not loaded. If
I load it manually with modprobe it appears to load without errors, but
the output of the checker-script does not change.

I admit I don't know anything about msr, is this
possibly an Intel specific thing?

Gruss

Michael

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

[Sven Hartge]

Michael Lange  wrote:
> On Fri, 26 Jan 2018 18:38:23 +0100 Sven Hartge  wrote:
>> Michael Lange  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 :)

No. The kernel from Sid has support for MSR as module:

root@host:~# modinfo msr
filename: /lib/modules/4.14.0-3-amd64/kernel/arch/x86/kernel/msr.ko
license:GPL
description:x86 generic MSR driver
author: H. Peter Anvin 
depends:
intree: Y
name:   msr
vermagic:   4.14.0-3-amd64 SMP mod_unload modversions 

Did you run the script as user or as root?

I get the same errors as you if I don't run the script as root. For the
checks to be reliable, *including* the dmesg-check, you need to run the
script as root.

Grüße,
Sven.

-- 
Sigmentation fault. Core dumped.

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

[Michael Lange]

On Fri, 26 Jan 2018 18:38:23 +0100
Sven Hartge  wrote:

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

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

[Michael Fothergill]

​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



>

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

[Greg Wooledge]

On Fri, Jan 26, 2018 at 06:07:13PM +0100, Michael Lange wrote:
> 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:

You shouldn't have to assume.  /proc/version tells you which compiler
was used.

wooledg:~$ cat /proc/version
Linux version 4.9.0-5-amd64 (debian-ker...@lists.debian.org) (gcc version 6.3.0 
20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.9.65-3+deb9u2 (2018-01-04)

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

[Michael Lange]

Hi,

On Fri, 26 Jan 2018 22:48:51 +0530
"tv.deb...@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

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

[Sven Hartge]

Michael Lange  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.

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

[Michael Fothergill]

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

> On 26/01/2018 22:37, Michael Lange wrote:
>
>> On Fri, 26 Jan 2018 22:19:27 +0530
>> "tv.deb...@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"...
>
>

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

[Michael Fothergill]

On 26 January 2018 at 16:49, tv.deb...@googlemail.com <
tv.deb...@googlemail.com> wrote:

> On 26/01/2018 22:08, Michael Lange wrote:
>
>> Hi,
>>
>> On Fri, 26 Jan 2018 21:34:51 +0530
>> "tv.deb...@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,


​That's what someone said to me earlier, but when I installed gcc7 as sid
the other day it said I had installed 7.2.20 or something and I did wonder
if it really was 7.3-rc instead
but I don't think apt-cache or some other fantastic search tool would tell
me that

I seem to recall other people saying it wouldn't work so instead of
reaching for dowsing rod or a ouija board I installed GCC8.

MF​



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

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

[tv.deb...@googlemail.com]

On 26/01/2018 22:37, Michael Lange wrote:

On Fri, 26 Jan 2018 22:19:27 +0530
"tv.deb...@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"...

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

[Michael Fothergill]

On 26 January 2018 at 16:37, Greg Wooledge  wrote:

> On Fri, Jan 26, 2018 at 04:17:27PM +, 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

​

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

[Michael Lange]

On Fri, 26 Jan 2018 22:19:27 +0530
"tv.deb...@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

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

[Michael Fothergill]

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

>
>
> On 26 January 2018 at 16:17, Michael Fothergill <
> michael.fotherg...@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=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.
>>>
>>>
>>
>

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

[tv.deb...@googlemail.com]

On 26/01/2018 22:08, Michael Lange wrote:

Hi,

On Fri, 26 Jan 2018 21:34:51 +0530
"tv.deb...@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.

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

[Michael Lange]

On Fri, 26 Jan 2018 16:17:27 +
Michael Fothergill  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

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

[Michael Fothergill]

On 26 January 2018 at 16:17, Michael Fothergill <
michael.fotherg...@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.
>>
>>
>

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

[Michael Lange]

Hi,

On Fri, 26 Jan 2018 21:34:51 +0530
"tv.deb...@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

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

[Greg Wooledge]

On Fri, Jan 26, 2018 at 04:17:27PM +, 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.

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

[Michael Fothergill]

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

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

[tv.deb...@googlemail.com]

On 26/01/2018 19:35, Michael Fothergill wrote:

On 25 January 2018 at 23:28, Michael Lange  wrote:


Hi,

On Thu, 25 Jan 2018 22:23:38 +
Michael Fothergill  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-h...@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.

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

[Michael Lange]

Hi,

On Fri, 26 Jan 2018 14:05:12 +
Michael Fothergill  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-h...@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

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

[Michael Fothergill]

On 25 January 2018 at 23:28, Michael Lange  wrote:

> Hi,
>
> On Thu, 25 Jan 2018 22:23:38 +
> Michael Fothergill  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-h...@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
>
>

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

[Michael Lange]

Hi,

On Thu, 25 Jan 2018 22:23:38 +
Michael Fothergill  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