SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Generic Kernel Version 5.15.58.kjh is running fine on my Slackware64 15.0 + Multilib LapTop.
I've got a big pile of work to finish this weekend so I'll have to tackle the no-retbleed kernel later.
But then again, maybe booting with the mitigations=no commandline flag would be sufficient for me ?
If all you want to experiment with is turning off retbleed mitigations, boot with retbleed=off.
If you wanted to turn off a few other mitigations that have crept in lately that effect performance, you could try something like "srbds=off mmio_stale_data=off retbleed=off". Doing mitigations=off might be a bit overkill. In the end it'll be up to you to weigh the performance vs risk.
this is wrong, it will only tell you if you compiled these options or not
Are you sure I'm wrong? Have you tried it? It clearly states all the vulnerabilities the kernel knows about, next to those if the CPU is vulnerable or not, and next to that if mitigations are in place. Below is an example of a vulnerability mitigated, one not mitigated, and one that doesnt affect the cpu. This from a 5.18.x series kernel.
Like bassmadrigal, I've compared it to spectre-meltdown-checker, and received the same results.
Below is the text from the mitigations section ( I added bold and color=red LQ Tags to hilight the scary text for full disclosure )
I don't have an opinion on `lscpu` -vs- `cat /sys/devices/system/cpu/vulnerabilities` -vs- `spectre-meltdown-checker.sh`.
I would think that `lscpu` and `cat /sys/devices/system/cpu/vulnerabilities` will be as up-to-date as your kernel
I do see that spectre-meltdown-checker.sh v0.45 code was released 2022, Mar 27 ... reasonably up-to-date but does it know about the latest vulnerabilities ( ??? mmio and retbleeed ??? ) ?
But then-again, I don't see the retbleed=off Kernel CommandLine Option among the mitigations= section ... while there is a section specific to retbleed ...( edit: Thank you for the head's up, avian )
-- kjh
Code:
mitigations=
[X86,PPC,S390,ARM64] Control optional mitigations for
CPU vulnerabilities. This is a set of curated,
arch-independent options, each of which is an
aggregation of existing arch-specific options.
off
Disable all optional CPU mitigations. This
improves system performance, but it may also
expose users to several CPU vulnerabilities.
Equivalent to: nopti [X86,PPC]
kpti=0 [ARM64]
nospectre_v1 [X86,PPC]
nobp=0 [S390]
nospectre_v2 [X86,PPC,S390,ARM64]
spectre_v2_user=off [X86]
spec_store_bypass_disable=off [X86,PPC]
ssbd=force-off [ARM64]
l1tf=off [X86]
mds=off [X86]
tsx_async_abort=off [X86]
kvm.nx_huge_pages=off [X86]
srbds=off [X86,INTEL]
no_entry_flush [PPC]
no_uaccess_flush [PPC]
mmio_stale_data=off [X86]
Exceptions:
This does not have any effect on
kvm.nx_huge_pages when
kvm.nx_huge_pages=force.
auto (default)
Mitigate all CPU vulnerabilities, but leave SMT
enabled, even if it's vulnerable. This is for
users who don't want to be surprised by SMT
getting disabled across kernel upgrades, or who
have other ways of avoiding SMT-based attacks.
Equivalent to: (default behavior)
auto,nosmt
Mitigate all CPU vulnerabilities, disabling SMT
if needed. This is for users who always want to
be fully mitigated, even if it means losing SMT.
Equivalent to: l1tf=flush,nosmt [X86]
mds=full,nosmt [X86]
tsx_async_abort=full,nosmt [X86]
mmio_stale_data=full,nosmt [X86]
This is the explicit entry for retbleed
Code:
retbleed=
[X86] Control mitigation of RETBleed (Arbitrary
Speculative Code Execution with Return Instructions)
vulnerability.
off - no mitigation
auto - automatically select a migitation
auto,nosmt - automatically select a mitigation,
disabling SMT if necessary for
the full mitigation (only on Zen1
and older without STIBP).
ibpb - mitigate short speculation windows on
basic block boundaries too. Safe, highest
perf impact.
unret - force enable untrained return thunks,
only effective on AMD f15h-f17h
based systems.
unret,nosmt - like unret, will disable SMT when STIBP
is not available.
Selecting 'auto' will choose a mitigation method at run
time according to the CPU.
Not specifying this option is equivalent to retbleed=auto.
Last edited by kjhambrick; 07-31-2022 at 03:10 PM.
Reason: Add a Thank You
There is some interesting arm64 news and then this,
Quote:
....Anyway, regardless of all that, this obviously means that the merge window (*) will open tomorrow. But please give this a good test run before you get all excited about a new development kernel.
Linus
(*) I'll likely call it 6.0 since I'm starting to worry about getting
confused by big numbers again.
Last edited by cwizardone; 07-31-2022 at 04:51 PM.
Distribution: Slackware64-current with "True Multilib" and KDE4Town.
Posts: 9,163
Original Poster
Rep:
FWIW, the new 5.19.0 kernel has been built and installed and running as it should on a first generation Zen CPU with a
Nvidia GPU using the nvidia-legacy470-driver-470.129.06_multilib-x86_64-1 (Sbo).
VirtualBox-6.1.36-152435-Linux_amd64 is working perfectly.
FWIW, the new 5.19.0 kernel has been built and installed and running as it should on a first generation Zen CPU with a
Nvidia GPU using the nvidia-legacy470-driver-470.129.06_multilib-x86_64-1 (Sbo).
VirtualBox-6.1.36-152435-Linux_amd64 is working perfectly.
FYI, I had to apply this patch because the nvidia-470.129.06 64bit module could not be compiled with the new 5.19 kernel.
Distribution: Slackware64-current with "True Multilib" and KDE4Town.
Posts: 9,163
Original Poster
Rep:
Year 2022, Round 47.
Another batch of updates has been scheduled for release on Wednesday, 3 August 2022, at approximately 11:00 GMT. If no problems are found while testing the release candidates, they might be available sometime on Tuesday (depending on your time zone).
Distribution: Slackware64-current with "True Multilib" and KDE4Town.
Posts: 9,163
Original Poster
Rep:
Quote:
Originally Posted by bathory
FYI, I had to apply this patch because the nvidia-470.129.06 64bit module could not be compiled with the new 5.19 kernel.
In the past I have always used the blob directly from Nvidia, but I got tired of waiting for them to update the 470 series and about ten or eleven days ago I downloaded this script from Slackbuild.org, http://www.slackbuilds.org/repositor...acy470-driver/
By following the directions on that page, the driver built (after building and installing the Nvidia kernel) and has worked just fine. I did see what looked like numerous errors during the build process, but once installed, it, as I said, it has worked just fine. Of course, you have to rebuild both of them every time you change the Linux kernel.
Last edited by cwizardone; 08-01-2022 at 09:27 AM.
OK, having problems booting 5.19 on current (new kernel today). elilo, huge kernel, not using an initrd. No error message or panic that I could see, just got the "done" message, then it popped me back to BIOS. (I'm using uefi.) runlevel 3
OK, having problems booting 5.19 on current (new kernel today). elilo, huge kernel, not using an initrd. No error message or panic that I could see, just got the "done" message, then it popped me back to BIOS. (I'm using uefi.) runlevel 3
ELILO problems on -current here too! I can still boot 5.18.15 with ELILO but not 5.19.0. Just reboots when it should load the initrd. I use mkinitrd.conf to generate the initrd.
GRUB boots 5.19.0 like a champ on the same machine. Odd for sure!
OK, having problems booting 5.19 on current (new kernel today). elilo, huge kernel, not using an initrd. No error message or panic that I could see, just got the "done" message, then it popped me back to BIOS. (I'm using uefi.) runlevel 3
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
I added bold and color=red LQ Tags to hilight the scary text for full disclosure 
