4:12 a.m.
Bonjour,
I just updated f27 and the new installed kernel
(4.15.3-300.fc27.x86_64), sends these messages at boot time:
kernel: Spectre V2 : Mitigation: Full generic retpoline
kernel: Spectre V2 : System may be vulnerable to spectre v2
What do they mean and what to do? Waiting for next kernel update?
Thank you.
--
François Patte
UFR de mathématiques et informatique
Laboratoire CNRS MAP5, UMR 8145
Université Paris Descartes
45, rue des Saints Pères
F-75270 Paris Cedex 06
Tél. +33 (0)6 7892 5822
http://www.math-info.univ-paris5.fr/~patte
5:59 a.m.
On 02/17/18 18:12, François Patte wrote:
I just updated f27 and the new installed kernel
(4.15.3-300.fc27.x86_64), sends these messages at boot time:
kernel: Spectre V2 : Mitigation: Full generic retpoline
kernel: Spectre V2 : System may be vulnerable to spectre v2
What do they mean and what to do? Waiting for next kernel update?
It may mean that your particular CPU is not fully protected by the recent kernel patches.
Cat the files in /sys/devices/system/cpu/vulnerabilities
FWIW, my systems have ....
[egreshko@acer vulnerabilities]$ cat meltdown
Mitigation: PTI
[egreshko@acer vulnerabilities]$ cat spectre_v1
Mitigation: __user pointer sanitization
[egreshko@acer vulnerabilities]$ cat spectre_v2
Mitigation: Full generic retpoline
--
A motto of mine is: When in doubt, try it out
6:25 a.m.
Le 17/02/2018 à 12:59, Ed Greshko a écrit :
On 02/17/18 18:12, François Patte wrote:
> I just updated f27 and the new installed kernel
> (4.15.3-300.fc27.x86_64), sends these messages at boot time:
>
> kernel: Spectre V2 : Mitigation: Full generic retpoline
> kernel: Spectre V2 : System may be vulnerable to spectre v2
>
> What do they mean and what to do? Waiting for next kernel update?
It may mean that your particular CPU is not fully protected by the recent kernel
patches.
Cat the files in /sys/devices/system/cpu/vulnerabilities
FWIW, my systems have ....
[egreshko@acer vulnerabilities]$ cat meltdown
Mitigation: PTI
[egreshko@acer vulnerabilities]$ cat spectre_v1
Mitigation: __user pointer sanitization
Same as you.
[egreshko@acer vulnerabilities]$ cat spectre_v2
Mitigation: Full generic retpoline
this one gives:
Mitigation: Full generic retpoline - vulnerable module loaded
But does not give the module name!!
--
François Patte
UFR de mathématiques et informatique
Laboratoire CNRS MAP5, UMR 8145
Université Paris Descartes
45, rue des Saints Pères
F-75270 Paris Cedex 06
Tél. +33 (0)6 7892 5822
http://www.math-info.univ-paris5.fr/~patte
7:32 a.m.
On 02/17/18 20:25, François Patte wrote:
> [egreshko@acer vulnerabilities]$ cat spectre_v2
> Mitigation: Full generic retpoline
this one gives:
Mitigation: Full generic retpoline - vulnerable module loaded
But does not give the module name!!
Do you have any modules, such as a Wifi driver, that you've built yourself?
--
A motto of mine is: When in doubt, try it out
9:48 a.m.
Le 17/02/2018 à 14:32, Ed Greshko a écrit :
On 02/17/18 20:25, François Patte wrote:
>> [egreshko@acer vulnerabilities]$ cat spectre_v2
>> Mitigation: Full generic retpoline
> this one gives:
>
> Mitigation: Full generic retpoline - vulnerable module loaded
>
> But does not give the module name!!
Do you have any modules, such as a Wifi driver, that you've built yourself?
No!
--
François Patte
UFR de mathématiques et informatique
Laboratoire CNRS MAP5, UMR 8145
Université Paris Descartes
45, rue des Saints Pères
F-75270 Paris Cedex 06
Tél. +33 (0)6 7892 5822
http://www.math-info.univ-paris5.fr/~patte
11:11 a.m.
On Sat, 17 Feb 2018 13:25:06 +0100
François Patte <francois.patte(a)mi.parisdescartes.fr> wrote:
Le 17/02/2018 à 12:59, Ed Greshko a écrit :
> On 02/17/18 18:12, François Patte wrote:
>> I just updated f27 and the new installed kernel
>> (4.15.3-300.fc27.x86_64), sends these messages at boot time:
>>
>> kernel: Spectre V2 : Mitigation: Full generic retpoline
>> kernel: Spectre V2 : System may be vulnerable to spectre v2
>>
>> What do they mean and what to do? Waiting for next kernel update?
>
>
> It may mean that your particular CPU is not fully protected by the recent kernel
patches.
>
> Cat the files in /sys/devices/system/cpu/vulnerabilities
>
> FWIW, my systems have ....
>
> [egreshko@acer vulnerabilities]$ cat meltdown
> Mitigation: PTI
>
> [egreshko@acer vulnerabilities]$ cat spectre_v1
> Mitigation: __user pointer sanitization
Same as you.
>
> [egreshko@acer vulnerabilities]$ cat spectre_v2
> Mitigation: Full generic retpoline
this one gives:
Mitigation: Full generic retpoline - vulnerable module loaded
But does not give the module name!!
You might want to try and see your last boot messages (or any logs for
might matter ...)
journalctl -b
Then search for Spectre and retpoline (maybe changing upper/lower case)
and the messages before and after these found instances .. look hard ...
If that does not help, you might try that: Just reboot, and see
whether that changes anything.
Still no joy? try this:
dnf list kernel\* --enablerepo=updates-testing
(this should nothing install, just check for updates in testing). See:
https://fedoraproject.org/wiki/QA:Updates_Testing#Enabling_the_repository...
and see whether there are updates in the pipeline to install (careful!) ..
or - next option, and again:careful! - install a vanilla kernel from a non-official
repo for Fedora - more on it here:
https://fedoraproject.org/wiki/Kernel_Vanilla_Repositories
On a F26 I have a 4.15 kernel installed recently from that repo, running
so far smoothly (didn't test it too hard, so far). But read the FAQ beforehand
mentioned on that page: These kernels don't have - IIRC - the kernels patched
specifically for Fedora. Just vanilla ...
Here:
% uname -srvm
Linux 4.15.3-300.vanilla.knurd.1.fc26.x86_64 #1 SMP Mon Feb 12 06:36:22 UTC 2018 x86_64
% grep . /sys/devices/system/cpu/vulnerabilities/*
/sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: __user pointer
sanitization
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full generic retpoline
HTH, and Good Luck!
Regards
--
Wolfgang Pfeiffer
12:10 p.m.
Le 17/02/2018 à 18:11, Wolfgang Pfeiffer a écrit :
On Sat, 17 Feb 2018 13:25:06 +0100
François Patte <francois.patte(a)mi.parisdescartes.fr> wrote:
> Le 17/02/2018 à 12:59, Ed Greshko a écrit :
>> On 02/17/18 18:12, François Patte wrote:
>>> I just updated f27 and the new installed kernel
>>> (4.15.3-300.fc27.x86_64), sends these messages at boot time:
>>>
>>> kernel: Spectre V2 : Mitigation: Full generic retpoline
>>> kernel: Spectre V2 : System may be vulnerable to spectre v2
>>>
>>> What do they mean and what to do? Waiting for next kernel update?
>>
>>
>> It may mean that your particular CPU is not fully protected by the recent kernel
patches.
>>
>> Cat the files in /sys/devices/system/cpu/vulnerabilities
>>
>> FWIW, my systems have ....
>>
>> [egreshko@acer vulnerabilities]$ cat meltdown
>> Mitigation: PTI
>>
>> [egreshko@acer vulnerabilities]$ cat spectre_v1
>> Mitigation: __user pointer sanitization
>
> Same as you.
>
>>
>> [egreshko@acer vulnerabilities]$ cat spectre_v2
>> Mitigation: Full generic retpoline
>
> this one gives:
>
> Mitigation: Full generic retpoline - vulnerable module loaded
>
> But does not give the module name!!
You might want to try and see your last boot messages (or any logs for
might matter ...)
journalctl -b
Then search for Spectre and retpoline (maybe changing upper/lower case)
and the messages before and after these found instances .. look hard ...
journalctl -b | grep -i retpoline
returns that virtualbox drivers (vboxdrv, vboxnetflt, vboxnetadp,
vboxpci) and nvidia driver were not compiled with a retpoline compiler....
As these modules are compiled on board with gcc using akmod, I suppose
that gcc is not a retpoline compiler.
What can I do?
--
François Patte
UFR de mathématiques et informatique
Laboratoire CNRS MAP5, UMR 8145
Université Paris Descartes
45, rue des Saints Pères
F-75270 Paris Cedex 06
Tél. +33 (0)6 7892 5822
http://www.math-info.univ-paris5.fr/~patte
1:31 p.m.
On 02/18/18 02:10, François Patte wrote:
returns that virtualbox drivers (vboxdrv, vboxnetflt, vboxnetadp,
vboxpci) and nvidia driver were not compiled with a retpoline compiler....
As these modules are compiled on board with gcc using akmod, I suppose
that gcc is not a retpoline compiler.
What can I do?
Where do you get your Vbox and nVidia drivers from?
I use rpmfusion (akmods) and vbox from Oracle. In these cases the modules are being
build locally and both cases the -DRETPOLINE flag is set in the compile. Here is the
gcc line in my /var/log/vbox-install.log file.
gcc -Wp,-MD,/tmp/vbox.0/.vboxpci.mod.o.d -nostdinc -isystem
/usr/lib/gcc/x86_64-redhat-linux/7/include -I./arch/x86/include
-I./arch/x86/include/generated -I./include -I./arch/x86/include/uapi
-I./arch/x86/include/generated/uapi -I./include/uapi -I./include/generated/uapi
-include ./include/linux/kconfig.h -D__KERNEL__ -Wall -Wundef -Wstrict-prototypes
-Wno-trigraphs -fno-strict-aliasing -fno-common -fshort-wchar
-Werror-implicit-function-declaration -Wno-format-security -std=gnu89 -fno-PIE
-mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -m64 -falign-jumps=1 -falign-loops=1
-mno-80387 -mno-fp-ret-in-387 -mpreferred-stack-boundary=3 -mskip-rax-setup
-mtune=generic -mno-red-zone -mcmodel=kernel -funit-at-a-time -DCONFIG_AS_CFI=1
-DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DCONFIG_AS_CFI_SECTIONS=1 -DCONFIG_AS_FXSAVEQ=1
-DCONFIG_AS_SSSE3=1 -DCONFIG_AS_CRC32=1 -DCONFIG_AS_AVX=1 -DCONFIG_AS_AVX2=1
-DCONFIG_AS_AVX512=1 -DCONFIG_AS_SHA1_NI=1 -DCONFIG_AS_SHA256_NI=1 -pipe
-Wno-sign-compare -fno-asynchronous-unwind-tables -mindirect-branch=thunk-extern
-mindirect-branch-register -DRETPOLINE -fno-delete-null-pointer-checks
-Wno-frame-address -Wno-format-truncation -Wno-format-overflow
-Wno-int-in-bool-context -O2 --param=allow-store-data-races=0 -DCC_HAVE_ASM_GOTO
-Wframe-larger-than=2048 -fstack-protector-strong -Wno-unused-but-set-variable
-Wno-unused-const-variable -fvar-tracking-assignments -g -pg -mfentry
-DCC_USING_FENTRY -Wdeclaration-after-statement -Wno-pointer-sign
-fno-strict-overflow -fno-stack-check -fconserve-stack -Werror=implicit-int
-Werror=strict-prototypes -Werror=date-time -Werror=incompatible-pointer-types
-Werror=designated-init -include /tmp/vbox.0/include/VBox/SUPDrvMangling.h -fno-pie
-I/lib/modules/4.15.3-300.fc27.x86_64/build/include -I/tmp/vbox.0/
-I/tmp/vbox.0/include -I/tmp/vbox.0/r0drv/linux -D__KERNEL__ -DMODULE -DRT_OS_LINUX
-DIN_RING0 -DIN_RT_R0 -DIN_SUP_R0 -DVBOX -DRT_WITH_VBOX -DVBOX_WITH_HARDENING
-DRT_ARCH_AMD64 -DKBUILD_BASENAME='"vboxpci.mod"'
-DKBUILD_MODNAME='"vboxpci"'
-DMODULE -c -o /tmp/vbox.0/vboxpci.mod.o /tmp/vbox.0/vboxpci.mod.c
--
A motto of mine is: When in doubt, try it out
3:12 p.m.
Le 17/02/2018 à 20:31, Ed Greshko a écrit :
On 02/18/18 02:10, François Patte wrote:
> returns that virtualbox drivers (vboxdrv, vboxnetflt, vboxnetadp,
> vboxpci) and nvidia driver were not compiled with a retpoline compiler....
>
> As these modules are compiled on board with gcc using akmod, I suppose
> that gcc is not a retpoline compiler.
>
> What can I do?
Where do you get your Vbox and nVidia drivers from?
rpmfusion, as akmods....
but
grep DRETPOLINE /var/log/vbox-install.log
and
grep DRETPOLINE
/var/cache/akmods/nvidia-340xx/340.106-1-for-4.15.3-300.fc27.x86_64.log
return nothing...
--
François Patte
UFR de mathématiques et informatique
Laboratoire CNRS MAP5, UMR 8145
Université Paris Descartes
45, rue des Saints Pères
F-75270 Paris Cedex 06
Tél. +33 (0)6 7892 5822
http://www.math-info.univ-paris5.fr/~patte
3:28 p.m.
On 02/18/18 05:12, François Patte wrote:
--
A motto of mine is: When in doubt, try it out
Le 17/02/2018 à 20:31, Ed Greshko a écrit :
> On 02/18/18 02:10, François Patte wrote:
>> returns that virtualbox drivers (vboxdrv, vboxnetflt, vboxnetadp,
>> vboxpci) and nvidia driver were not compiled with a retpoline compiler....
> >> As these modules are compiled on board with gcc using
akmod, I suppose
>> that gcc is not a retpoline compiler.
> >> What can I do?
> Where do you get your Vbox and nVidia drivers from?
rpmfusion, as akmods....
but
grep DRETPOLINE /var/log/vbox-install.log
What is the gcc line in that file?
and
grep DRETPOLINE
/var/cache/akmods/nvidia-340xx/340.106-1-for-4.15.3-300.fc27.x86_64.log
return nothing...
And what do you get for ....
strings /usr/lib/modules/4.15.3-300.fc27.x86_64/extra/nvidia/nvidia.ko | grep gcc
4:32 p.m.
Ed Greshko wrote:
On 02/18/18 05:12, François Patte wrote:
> Le 17/02/2018 à 20:31, Ed Greshko a écrit :
>> On 02/18/18 02:10, François Patte wrote:
>>> returns that virtualbox drivers (vboxdrv, vboxnetflt, vboxnetadp,
>>> vboxpci) and nvidia driver were not compiled with a retpoline compiler....
>>>
>>> As these modules are compiled on board with gcc using akmod, I suppose
>>> that gcc is not a retpoline compiler.
>>>
>>> What can I do?
>>
>> Where do you get your Vbox and nVidia drivers from?
> rpmfusion, as akmods....
>
> but
>
> grep DRETPOLINE /var/log/vbox-install.log
What is the gcc line in that file?
>
> and
>
> grep DRETPOLINE
> /var/cache/akmods/nvidia-340xx/340.106-1-for-4.15.3-300.fc27.x86_64.log
>
> return nothing...
I was curious about this myself recently. I think there is
a lack of detail in the nvidia kmod build logs because they
don't pass V=1 to the make command. This results in nice,
quiet build output. But for package builds it's preferable
to see the options used. I've submitted a patch to
rpmfusion for the nvidia-kmod package:
https://bugzilla.rpmfusion.org/4800
If that's accepted, I or someone else can work on adding the
same V=1 to the make command for the other nvidia-*-kmod
packages.
The difference with and without V=1 is quite a lot.
Without V=1:
https://paste.fedoraproject.org/paste/DCfHztA22~NI77Bhes~LOw
With V=1:
https://paste.fedoraproject.org/paste/jPkevkTHxq42boCeS5okyA
And to keep it more relevant to this thread, with the
verbose make I can see that -DRETPOLINE is used when
building the nvidia kmod on my f26 system.
Thanks for sending me on a fun hunt Ed. :)
--
Todd
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Curiosity killed the cat, but for awhile I was a suspect.
-- Steven Wright
4:41 p.m.
On 02/17/2018 02:32 PM, Todd Zullinger wrote:
If that's accepted, I or someone else can work on adding the
same V=1 to the make command for the other nvidia-*-kmod
packages.
The question is, how many people would want to see the extra output or
know what to do with it? I know people who'd have to be talked through
the process of reporting a bug, and having to save that output for the
report might be what makes them decide that it's too much bother. Yes,
having that parameter can be a good thing, but I don't know if it's
useful enough in general to be added.
4:51 p.m.
On 02/18/18 06:41, Joe Zeff wrote:
On 02/17/2018 02:32 PM, Todd Zullinger wrote:
> If that's accepted, I or someone else can work on adding the
> same V=1 to the make command for the other nvidia-*-kmod
> packages.
The question is, how many people would want to see the extra output or know what to
do with it? I know people who'd have to be talked through the process of reporting
a bug, and having to save that output for the report might be what makes them
decide that it's too much bother. Yes, having that parameter can be a good thing,
but I don't know if it's useful enough in general to be added.
It is going to be in a log file. So, you look or don't look. Up to you. Go to
/var/log and see how many other logs are generated that you never look at and contain
stuff most people won't understand.
--
A motto of mine is: When in doubt, try it out
4:58 p.m.
On 02/17/2018 02:51 PM, Ed Greshko wrote:
It is going to be in a log file. So, you look or don't look. Up
to you. Go to
/var/log and see how many other logs are generated that you never look at and contain
stuff most people won't understand.
I'm not saying that it shouldn't be done, just that we would need to
take that into consideration when deciding if it's a good idea. As long
as the average user doesn't need to see it, I agree that there's no
reason not to do it.
6:08 p.m.
On Sat, 17 Feb 2018 14:58:22 -0800
Joe Zeff <joe(a)zeff.us> wrote:
On 02/17/2018 02:51 PM, Ed Greshko wrote:
> It is going to be in a log file. So, you look or don't look. Up
> to you. Go to /var/log and see how many other logs are generated
> that you never look at and contain stuff most people won't
> understand.
I'm not saying that it shouldn't be done, just that we would need to
take that into consideration when deciding if it's a good idea. As
long as the average user doesn't need to see it, I agree that there's
no reason not to do it.
The average user coming to this list asking for help might hate
the fact that there are no logs he could show us to help him find a
solution.
Usually I am probably one of those average users not reading the logs
(who, usually, does anyways if there's no need to do it?) But as soon as
things go wrong what can we do, other than looking at the logs? At least
as long as there are no talking crystal balls being available out
there ... :)
I think I owe quite a bit of my still limited knowledge about computers
to the simple fact that I read the logs when needed. Remove the logs
from any OS you might think about - and I'd easily quit it in sec if I
find software with a decent and better logging system ....
Best Regards,
--
Wolfgang Pfeiffer
4:54 p.m.
Joe Zeff wrote:
On 02/17/2018 02:32 PM, Todd Zullinger wrote:
> If that's accepted, I or someone else can work on adding the
> same V=1 to the make command for the other nvidia-*-kmod
> packages.
The question is, how many people would want to see the extra output or know
what to do with it? I know people who'd have to be talked through the
process of reporting a bug, and having to save that output for the report
might be what makes them decide that it's too much bother. Yes, having that
parameter can be a good thing, but I don't know if it's useful enough in
general to be added.
I'm of the opinion that builds logs should show the build
process in more detail rather than less. If someone doesn't
want to see the output, why are they looking through the
build logs of an automatically built kernel module?
Odds are good that most people looking through the logs are
trying to either confirm how it was built or diagnose a
problem. Both cases are helped by including more complete
build output. And both cases outweigh that of the user who
says "I don't like so much output in a file I don't
understand" in my opinion.
I don't have it at hand, but I believe that the Fedora
packaging guidelines include a requirement to use such
options. While that's not mandatory for a package which is
built on end-user systems, the same package source is built
in rpmfusion's build system and they do follow the Fedora
guidelines.
I also feel that anyone who gives up at attaching a file to
a bug report isn't likely to file a bug report worth filing. ;)
--
Todd
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If Stupidity got us into this mess, then why can't it get us out?
-- Will Rogers (1879-1935)
3:01 a.m.
Le 17/02/2018 à 22:28, Ed Greshko a écrit :
On 02/18/18 05:12, François Patte wrote:
> Le 17/02/2018 à 20:31, Ed Greshko a écrit :
>> On 02/18/18 02:10, François Patte wrote:
>>> returns that virtualbox drivers (vboxdrv, vboxnetflt, vboxnetadp,
>>> vboxpci) and nvidia driver were not compiled with a retpoline compiler....
>>>
>>> As these modules are compiled on board with gcc using akmod, I suppose
>>> that gcc is not a retpoline compiler.
>>>
>>> What can I do?
>>
>> Where do you get your Vbox and nVidia drivers from?
> rpmfusion, as akmods....
>
> but
>
> grep DRETPOLINE /var/log/vbox-install.log
What is the gcc line in that file?
As there are 2694 occurences of gcc -Wp,-MD, in this file (and no date
is given in the file...), I suppose that the last occurence, is the last
build of vbox modules...):
gcc -Wp,-MD,/tmp/vbox.0/.vboxpci.mod.o.d -nostdinc -isystem
/usr/lib/gcc/x86_64-redhat-linux/7/include -I./arch/x86/include
-I./arch/x86/include/generated -I./include -I./arch/x86/include/uapi
-I./arch/x86/include/generated/uapi -I./include/uapi
-I./include/generated/uapi -include ./include/linux/kconfig.h
-D__KERNEL__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs
-fno-strict-aliasing -fno-common -fshort-wchar
-Werror-implicit-function-declaration -Wno-format-security -std=gnu89
-fno-PIE -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -m64
-falign-jumps=1 -falign-loops=1 -mno-80387 -mno-fp-ret-in-387
-mpreferred-stack-boundary=3 -mskip-rax-setup -mtune=generic
-mno-red-zone -mcmodel=kernel -funit-at-a-time -DCONFIG_AS_CFI=1
-DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DCONFIG_AS_CFI_SECTIONS=1
-DCONFIG_AS_FXSAVEQ=1 -DCONFIG_AS_SSSE3=1 -DCONFIG_AS_CRC32=1
-DCONFIG_AS_AVX=1 -DCONFIG_AS_AVX2=1 -DCONFIG_AS_AVX512=1
-DCONFIG_AS_SHA1_NI=1 -DCONFIG_AS_SHA256_NI=1 -pipe -Wno-sign-compare
-fno-asynchronous-unwind-tables -fno-delete-null-pointer-checks
-Wno-frame-address -Wno-format-truncation -Wno-format-overflow
-Wno-int-in-bool-context -O2 --param=allow-store-data-races=0
-DCC_HAVE_ASM_GOTO -Wframe-larger-than=2048 -fstack-protector-strong
-Wno-unused-but-set-variable -Wno-unused-const-variable
-fno-omit-frame-pointer -fno-optimize-sibling-calls
-fvar-tracking-assignments -g -pg -mfentry -DCC_USING_FENTRY
-Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow
-fno-stack-check -fconserve-stack -Werror=implicit-int
-Werror=strict-prototypes -Werror=date-time
-Werror=incompatible-pointer-types -Werror=designated-init -include
/tmp/vbox.0/include/VBox/SUPDrvMangling.h
-I/lib/modules/4.14.13-300.fc27.x86_64/build/include -I/tmp/vbox.0/
-I/tmp/vbox.0/include -I/tmp/vbox.0/r0drv/linux -I/tmp/vbox.0/vboxpci/
-I/tmp/vbox.0/vboxpci/include -I/tmp/vbox.0/vboxpci/r0drv/linux
-D__KERNEL__ -DMODULE -DRT_OS_LINUX -DIN_RING0 -DIN_RT_R0 -DIN_SUP_R0
-DVBOX -DRT_WITH_VBOX -DVBOX_WITH_HARDENING -DRT_ARCH_AMD64
-DVBOX_WITH_64_BITS_GUESTS -fno-pie -DKBUILD_BASENAME='"vboxpci.mod"'
-DKBUILD_MODNAME='"vboxpci"' -DMODULE -c -o /tmp/vbox.0/vboxpci.mod.o
/tmp/vbox.0/vboxpci.mod.c
>
> and
>
> grep DRETPOLINE
> /var/cache/akmods/nvidia-340xx/340.106-1-for-4.15.3-300.fc27.x86_64.log
>
> return nothing...
And what do you get for ....
strings /usr/lib/modules/4.15.3-300.fc27.x86_64/extra/nvidia/nvidia.ko | grep gcc
$ strings
/usr/lib/modules/4.15.3-300.fc27.x86_64/extra/nvidia-340xx/nvidia.ko |
grep gcc
gcc version 7.2.1 20170915 (Red Hat 7.2.1-2) (GCC)
--
François Patte
UFR de mathématiques et informatique
Laboratoire CNRS MAP5, UMR 8145
Université Paris Descartes
45, rue des Saints Pères
F-75270 Paris Cedex 06
Tél. +33 (0)6 7892 5822
http://www.math-info.univ-paris5.fr/~patte
3:54 a.m.
On 02/18/18 17:01, François Patte wrote:
$ strings
/usr/lib/modules/4.15.3-300.fc27.x86_64/extra/nvidia-340xx/nvidia.ko |
grep gcc
gcc version 7.2.1 20170915 (Red Hat 7.2.1-2) (GCC)
OK. I believe that RETPOLINE support isn't available in that version of gcc.
gcc-7.3.1-2.fc27 is the current version
I think if you upgrade to the most recent version your problem will be fixed when the
modules are rebuilt
--
A motto of mine is: When in doubt, try it out
4:14 a.m.
Le 18/02/2018 à 10:54, Ed Greshko a écrit :
On 02/18/18 17:01, François Patte wrote:
> $ strings
> /usr/lib/modules/4.15.3-300.fc27.x86_64/extra/nvidia-340xx/nvidia.ko |
> grep gcc
>
> gcc version 7.2.1 20170915 (Red Hat 7.2.1-2) (GCC)
OK. I believe that RETPOLINE support isn't available in that version of gcc.
gcc-7.3.1-2.fc27 is the current version
I think if you upgrade to the most recent version your problem will be fixed when the
modules are rebuilt
fc27 is the last "stable" version of fedora, and gcc-7.3 seems to have a
patch for retpoline, why the patched version is not available in fedora
repos?
--
François Patte
UFR de mathématiques et informatique
Laboratoire CNRS MAP5, UMR 8145
Université Paris Descartes
45, rue des Saints Pères
F-75270 Paris Cedex 06
Tél. +33 (0)6 7892 5822
http://www.math-info.univ-paris5.fr/~patte
4:20 a.m.
On 02/18/18 18:14, François Patte wrote:
fc27 is the last "stable" version of fedora, and gcc-7.3
seems to have a
patch for retpoline, why the patched version is not available in fedora
repos?
What do you mean it isn't available in the repo? That is where mine came from.
[egreshko@meimei ~]$ dnf list gcc
Last metadata expiration check: 3 days, 20:12:19 ago on Wed 14 Feb 2018 10:07:18 PM CST.
Installed Packages
gcc.x86_64 7.3.1-2.fc27 @updates
--
A motto of mine is: When in doubt, try it out
7:03 a.m.
Le 18/02/2018 à 11:20, Ed Greshko a écrit :
On 02/18/18 18:14, François Patte wrote:
> fc27 is the last "stable" version of fedora, and gcc-7.3 seems to have a
> patch for retpoline, why the patched version is not available in fedora
> repos?
What do you mean it isn't available in the repo? That is where mine came from.
[egreshko@meimei ~]$ dnf list gcc
Last metadata expiration check: 3 days, 20:12:19 ago on Wed 14 Feb 2018 10:07:18 PM CST.
Installed Packages
gcc.x86_64 7.3.1-2.fc27 @updates
Strangely, gcc was not proposed for update yesterday, it is today, so I
updated it but I am unable to reinstall virtualbox or nvidia drivers
--
François Patte
UFR de mathématiques et informatique
Laboratoire CNRS MAP5, UMR 8145
Université Paris Descartes
45, rue des Saints Pères
F-75270 Paris Cedex 06
Tél. +33 (0)6 7892 5822
http://www.math-info.univ-paris5.fr/~patte
7:19 a.m.
On Sun, 18 Feb 2018 14:03:31 +0100
François Patte <francois.patte(a)mi.parisdescartes.fr> wrote:
Le 18/02/2018 à 11:20, Ed Greshko a écrit :
> On 02/18/18 18:14, François Patte wrote:
>> fc27 is the last "stable" version of fedora, and gcc-7.3 seems to have
a
>> patch for retpoline, why the patched version is not available in fedora
>> repos?
>
>
> What do you mean it isn't available in the repo? That is where mine came
from.
>
> [egreshko@meimei ~]$ dnf list gcc
> Last metadata expiration check: 3 days, 20:12:19 ago on Wed 14 Feb 2018 10:07:18 PM
CST.
> Installed Packages
> gcc.x86_64 7.3.1-2.fc27 @updates
Strangely, gcc was not proposed for update yesterday, it is today, so I
updated it but I am unable to reinstall virtualbox or nvidia drivers
Why? What happened? There's an option to reinstall software with dnf:
excerpt: man dnf:
------------------------
Reinstall Command
dnf [options] reinstall <package-specs>...
Installs the specified packages, fails if some of the packages
are either not installed or not available (i.e. there is no
repository where to download the same RPM).
-------------------------
--
Wolfgang Pfeiffer
7:22 a.m.
On 02/18/18 21:03, François Patte wrote:
Le 18/02/2018 à 11:20, Ed Greshko a écrit :
> On 02/18/18 18:14, François Patte wrote:
>> fc27 is the last "stable" version of fedora, and gcc-7.3 seems to have
a
>> patch for retpoline, why the patched version is not available in fedora
>> repos?
>
> What do you mean it isn't available in the repo? That is where mine came from.
>
> [egreshko@meimei ~]$ dnf list gcc
> Last metadata expiration check: 3 days, 20:12:19 ago on Wed 14 Feb 2018 10:07:18 PM
CST.
> Installed Packages
> gcc.x86_64 7.3.1-2.fc27 @updates
Strangely, gcc was not proposed for update yesterday, it is today, so I
updated it but I am unable to reinstall virtualbox or nvidia drivers
FWIW, the gcc update on my system happened on 2/7
For nvidia you can run....
/sbin/akmodsbuild --target x86_64 --kernels `uname -r` /usr/src/akmods/nvidia-kmod.latest
Which will create a kmod-nvidia-4.15.3-300.fc27.x86_64-390.25-3.fc27.x86_64.rpm and
you can either use "dnf reinstall" or use rpm to install with the --force.
--
A motto of mine is: When in doubt, try it out
7:59 a.m.
Le 18/02/2018 à 14:22, Ed Greshko a écrit :
On 02/18/18 21:03, François Patte wrote:
> Le 18/02/2018 à 11:20, Ed Greshko a écrit :
>> On 02/18/18 18:14, François Patte wrote:
>>> fc27 is the last "stable" version of fedora, and gcc-7.3 seems to
have a
>>> patch for retpoline, why the patched version is not available in fedora
>>> repos?
>>
>> What do you mean it isn't available in the repo? That is where mine came
from.
>>
>> [egreshko@meimei ~]$ dnf list gcc
>> Last metadata expiration check: 3 days, 20:12:19 ago on Wed 14 Feb 2018 10:07:18
PM CST.
>> Installed Packages
>> gcc.x86_64 7.3.1-2.fc27
@updates
> Strangely, gcc was not proposed for update yesterday, it is today, so I
> updated it but I am unable to reinstall virtualbox or nvidia drivers
FWIW, the gcc update on my system happened on 2/7
For nvidia you can run....
/sbin/akmodsbuild --target x86_64 --kernels `uname -r`
/usr/src/akmods/nvidia-kmod.latest
Which will create a kmod-nvidia-4.15.3-300.fc27.x86_64-390.25-3.fc27.x86_64.rpm and
you can either use "dnf reinstall" or use rpm to install with the --force.
This solved the vulnerability for the nvidia module
--
François Patte
UFR de mathématiques et informatique
Laboratoire CNRS MAP5, UMR 8145
Université Paris Descartes
45, rue des Saints Pères
F-75270 Paris Cedex 06
Tél. +33 (0)6 7892 5822
http://www.math-info.univ-paris5.fr/~patte
7:55 a.m.
Le 18/02/2018 à 14:36, Ed Greshko a écrit :
On 02/18/18 21:03, François Patte wrote:
> but I am unable to reinstall virtualbox
For the virtualbox drivers just run...
sudo /usr/lib/virtualbox/vboxdrv.sh setup
This file (vboxdrv.sh) does not exist on my system... Are we running the
same f27?
--
François Patte
UFR de mathématiques et informatique
Laboratoire CNRS MAP5, UMR 8145
Université Paris Descartes
45, rue des Saints Pères
F-75270 Paris Cedex 06
Tél. +33 (0)6 7892 5822
http://www.math-info.univ-paris5.fr/~patte
7:58 a.m.
On 02/18/18 21:55, François Patte wrote:
Le 18/02/2018 à 14:36, Ed Greshko a écrit :
> On 02/18/18 21:03, François Patte wrote:
>> but I am unable to reinstall virtualbox
>
> For the virtualbox drivers just run...
>
> sudo /usr/lib/virtualbox/vboxdrv.sh setup
This file (vboxdrv.sh) does not exist on my system... Are we running the
same f27?
It could be different if you are getting Virtual Box from rpmfusion as opposed to
getting it directly from Oracle as I am.
--
A motto of mine is: When in doubt, try it out
3:17 p.m.
On 18/2/18 9:14 pm, François Patte wrote:
Le 18/02/2018 à 10:54, Ed Greshko a écrit :
> On 02/18/18 17:01, François Patte wrote:
>> $ strings
>> /usr/lib/modules/4.15.3-300.fc27.x86_64/extra/nvidia-340xx/nvidia.ko |
>> grep gcc
>>
>> gcc version 7.2.1 20170915 (Red Hat 7.2.1-2) (GCC)
>
> OK. I believe that RETPOLINE support isn't available in that version of gcc.
>
> gcc-7.3.1-2.fc27 is the current version
>
> I think if you upgrade to the most recent version your problem will be fixed when
the
> modules are rebuilt
fc27 is the last "stable" version of fedora, and gcc-7.3 seems to have a
patch for retpoline, why the patched version is not available in fedora
repos?
GCC 7.3 is in the Fedora Updates repository, check
/etc/yum.repos.d/fedora-updates.repo to see if you have the updates
repository enabled.
Just a slightly off topic question, in verifying where gcc comes from, I
did a dnf list gcc and dnf info gcc, the first command says the
installed package is in @updates, whereas the 2nd command says the repo
is @system and 'from repo' is updates, why are they different and why
does the 2nd command say the repo is @system when the package has only
ever been installed by dnf? I thought the output showed @system only
when it had been installed by rpm?
regards,
Steve
>
>
> _______________________________________________
> users mailing list -- users(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
2:59 p.m.
On 18/2/18 8:28 am, Ed Greshko wrote:
On 02/18/18 05:12, François Patte wrote:
> Le 17/02/2018 à 20:31, Ed Greshko a écrit :
>> On 02/18/18 02:10, François Patte wrote:
>>> returns that virtualbox drivers (vboxdrv, vboxnetflt, vboxnetadp,
>>> vboxpci) and nvidia driver were not compiled with a retpoline compiler....
>>>
>>> As these modules are compiled on board with gcc using akmod, I suppose
>>> that gcc is not a retpoline compiler.
>>>
>>> What can I do?
>> Where do you get your Vbox and nVidia drivers from?
> rpmfusion, as akmods....
>
> but
>
> grep DRETPOLINE /var/log/vbox-install.log
What is the gcc line in that file?
> and
>
> grep DRETPOLINE
> /var/cache/akmods/nvidia-340xx/340.106-1-for-4.15.3-300.fc27.x86_64.log
>
> return nothing...
And what do you get for ....
strings /usr/lib/modules/4.15.3-300.fc27.x86_64/extra/nvidia/nvidia.ko | grep gcc
I get my nvidia source from the negativo17 repository and all this
command does is list the version of gcc used. Following Todd's thread,
as my nvidia, wifi and mouse drivers (the wifi and mouse kernel drivers
are sourced from github, the wifi driver is downloaded manually and the
mouse driver is sourced from Razer's F27 repository) are all compiled
through dkms (I do have the akmods version of nvidia from negativo17 as
a backup to dkms), I can add the V=1 parameter to make in the dkms.conf
file. The only issue with this is at the moment I'm not sure where the
log files are kept.
regards,
Steve
>
>
>
> _______________________________________________
> users mailing list -- users(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
3:55 p.m.
On 02/19/18 04:59, Stephen Morris wrote:
>
> strings /usr/lib/modules/4.15.3-300.fc27.x86_64/extra/nvidia/nvidia.ko | grep gcc
I get my nvidia source from the negativo17 repository and all this command does is
list the version of gcc used
And that was the entire purpose of asking that question. To determine the version of
the compiler used. This then verified that the OP's compiler was out of date and
lacking retpoline support.
--
A motto of mine is: When in doubt, try it out
2:31 p.m.
On 17/2/18 10:59 pm, Ed Greshko wrote:
On 02/17/18 18:12, François Patte wrote:
> I just updated f27 and the new installed kernel
> (4.15.3-300.fc27.x86_64), sends these messages at boot time:
>
> kernel: Spectre V2 : Mitigation: Full generic retpoline
> kernel: Spectre V2 : System may be vulnerable to spectre v2
>
> What do they mean and what to do? Waiting for next kernel update?
It may mean that your particular CPU is not fully protected by the recent kernel
patches.
Cat the files in /sys/devices/system/cpu/vulnerabilities
FWIW, my systems have ....
[egreshko@acer vulnerabilities]$ cat meltdown
Mitigation: PTI
Mine says 'Not affected'.
[egreshko@acer vulnerabilities]$ cat spectre_v1
Mitigation: __user pointer sanitization
Mine is the same.
[egreshko@acer vulnerabilities]$ cat spectre_v2
Mitigation: Full generic retpoline
Mine says 'Mitigation: Full AMD retpoline'.
regards,
Steve
>
>
> _______________________________________________
> users mailing list -- users(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
2286
days inactive
2287
days old
32 comments
7 participants
participants (7)
-
Ed Greshko -
Ed Greshko -
François Patte -
Joe Zeff -
Stephen Morris -
Todd Zullinger -
Wolfgang Pfeiffer