Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
spectre and meltdown questions
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3  
Reply to topic    Gentoo Forums Forum Index Networking & Security
View previous topic :: View next topic  
Author Message
rogge
Tux's lil' helper
Tux's lil' helper


Joined: 13 Oct 2006
Posts: 105
Location: Erfurt

PostPosted: Thu Apr 09, 2020 9:16 am    Post subject: Re: mitigations=auto Reply with quote

Atha wrote:
With recent kernels including the new mitigations=[off|auto|auto,nosmt] kernel paramenter, I thought I'd post the options I use for a system as secure as possible... (though I might have gotten them wrong...)

All kernel boot parameters are listed in /usr/src/linux/Documentation/admin-guide/kernel-parameters.txt. I added those shown above to GRUB_CMDLINE_LINUX in /etc/default/grub. After running grub-mkconfig -o /boot/grub/grub.cfg (or whatever you're using, naturally /boot must be mounted) GRUB then uses the new boot parameters for the kernel.


Hi,

is there any chance for lilo users, too?

Regards, rogge
Back to top
View user's profile Send private message
saellaven
Guru
Guru


Joined: 23 Jul 2006
Posts: 576

PostPosted: Thu Apr 09, 2020 5:40 pm    Post subject: Re: mitigations=auto Reply with quote

rogge wrote:
Atha wrote:
With recent kernels including the new mitigations=[off|auto|auto,nosmt] kernel paramenter, I thought I'd post the options I use for a system as secure as possible... (though I might have gotten them wrong...)

All kernel boot parameters are listed in /usr/src/linux/Documentation/admin-guide/kernel-parameters.txt. I added those shown above to GRUB_CMDLINE_LINUX in /etc/default/grub. After running grub-mkconfig -o /boot/grub/grub.cfg (or whatever you're using, naturally /boot must be mounted) GRUB then uses the new boot parameters for the kernel.


Hi,

is there any chance for lilo users, too?

Regards, rogge


Just add it under your append line...

for example:

Code:

image=/boot/linux-5.6.2
       label=gentoo
       root=/dev/sda2
       append="mitigations=off"

_________________
Ryzen 3700X, Asus Prime X570-Pro, 32 GB DDR4 3200, GeForce GTX 1660 Super
openrc-0.17, ~vanilla-sources, ~nvidia-drivers, gcc-9.3.0
Back to top
View user's profile Send private message
Ionen
Veteran
Veteran


Joined: 06 Dec 2018
Posts: 1418

PostPosted: Fri Apr 10, 2020 1:02 am    Post subject: Reply with quote

^ alternatively when building yourself you can also embed command line options in the kernel that will work regardless of how you boot, like:
Code:
CONFIG_CMDLINE_BOOL=y
CONFIG_CMDLINE="threadirqs mitigations=off snd_hda_intel.enable=1,0 root=..."
Back to top
View user's profile Send private message
Atha
Apprentice
Apprentice


Joined: 22 Sep 2004
Posts: 184

PostPosted: Wed Jul 15, 2020 12:27 pm    Post subject: Reply with quote

Special Register Buffer Data Sampling (SRBDS), CVE-2020-0543, also known as "Crosstalk".

Code:
# uname -r -v
5.7.8-gentoo #1 SMP Sat Jul 11 18:55:39 CEST 2020

# dmesg -t | grep "LENOVO 2325AZ8"
DMI: LENOVO 2325AZ8/2325AZ8, BIOS G2ETB7WW (2.77 ) 09/24/2019

# dmesg -t | grep "microcode"
SRBDS: Vulnerable: No microcode
microcode: sig=0x306a9, pf=0x10, revision=0x21
microcode: Microcode Update Driver: v2.2.

# cat /proc/cpuinfo | grep -m 2 -e "bugs" -e "model name"
model name      : Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz
bugs            : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit srbds

# grep . /sys/devices/system/cpu/vulnerabilities/*
/sys/devices/system/cpu/vulnerabilities/itlb_multihit:KVM: Mitigation: Split huge pages
/sys/devices/system/cpu/vulnerabilities/l1tf:Mitigation: PTE Inversion; VMX: cache flushes, SMT disabled
/sys/devices/system/cpu/vulnerabilities/mds:Mitigation: Clear CPU buffers; SMT disabled
/sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI
/sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Mitigation: Speculative Store Bypass disabled
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: usercopy/swapgs barriers and __user pointer sanitization
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full generic retpoline, IBPB: conditional, IBRS_FW, RSB filling
/sys/devices/system/cpu/vulnerabilities/srbds:Vulnerable: No microcode
/sys/devices/system/cpu/vulnerabilities/tsx_async_abort:Not affected


Great. I don't see any new firmware/microcode for this Sandy Bridge Intel Core i 2nd generation CPU coming, although according to Phoronix Intel shipped new microcode in May 2020 specifically for Sandy Bridge Xeons.

What's wrong with you, Intel?!? Why not supply new microcode and continue fixing a failure that was detected almost two years ago (in Sept. 2018)?!?

BTW, Phoronix also benchmarked the impact of the SRBDS fix, showing high theoretical but low real-life impact. I wonder what's keeping Intel from providing this fix for every affected CPU... (mine is 06-58-09 - no microcode yet...)

Update: I just realized, the Sandy Bridge CPU is in the other computer... :roll:
The Core i5-3320M is Ivy Bridge, 3rd generation Core i, but still: no microcode...
_________________
Think for yourself and let others enjoy the privilege of doing so too. Voltaire


Last edited by Atha on Thu Jul 16, 2020 3:51 pm; edited 1 time in total
Back to top
View user's profile Send private message
Ant P.
Watchman
Watchman


Joined: 18 Apr 2009
Posts: 6778

PostPosted: Wed Jul 15, 2020 11:19 pm    Post subject: Reply with quote

Atha wrote:
What's wrong with you, Intel?!? Why not supply new microcode and continue fixing a failure that was detected almost two years ago?!?

To be fair here, Intel isn't the only company that sucks at supporting old chips:
lscpu:
Model name:                      AMD E-350 Processor
Vulnerability Itlb multihit:     Not affected
Vulnerability L1tf:              Not affected
Vulnerability Mds:               Not affected
Vulnerability Meltdown:          Not affected
Vulnerability Spec store bypass: Vulnerable               <----
Vulnerability Spectre v1:        Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Vulnerability Spectre v2:        Mitigation; Full AMD retpoline, STIBP disabled, RSB filling
Vulnerability Srbds:             Not affected
Vulnerability Tsx async abort:   Not affected
Back to top
View user's profile Send private message
Atha
Apprentice
Apprentice


Joined: 22 Sep 2004
Posts: 184

PostPosted: Thu Jul 16, 2020 11:53 am    Post subject: Reply with quote

Ant P. wrote:
To be fair here, Intel isn't the only company that sucks at supporting old chips:
lscpu:
Model name:                      AMD E-350 Processor
Vulnerability Spec store bypass: Vulnerable               <----

There is no way to fix spec_store_bypass, the only mitigation is to disable it. This works for AMD as it does for Intel, by configuring the kernel or by using the appropriate kernel commandline parameter spec_store_bypass_disable=on, e.g. in /etc/default/grub.
/etc/default/grub:
GRUB_CMDLINE_LINUX="mitigations=auto,nosmt spec_store_bypass_disable=on"

Then you should get this:
grep . /sys/devices/system/cpu/vulnerabilities/*:
spec_store_bypass:Mitigation: Speculative Store Bypass disabled


I recommend the safest possible settings, which are different for Intel and AMD (please refer to this posting). The kernel developers don't preset the safest mitigations by default, because of the likelyness of them being exploited vs. the impact on performance.

And to be completely fair:
AMD is vunlerable to three design flaws: Spectre v1 and v2 as well as Speculative Store Bypass. All of them can be mitigated. For Spectre v2 some older CPUs did not get firmware/ucode updates, which would have been required for the mitigation to fully work.
Intel is vulnerable to 5 or 6 more flaws in the design, i.e. the situation is 2-3 times worse. Meltdown alone is the worst flaw a CPU can have, because it actively helps when an exploit of the other flaws takes place. The other vulnerabilities are just different variations of the same design flaws, and it is not comprehensible to me that they fix one but not the other. E.g. they fixed Microarchitectural Data Sampling (MDS), and SRBDS is just one special variant of the same thing, but needing a different mitigation. It needs firmware/microcode. See also CrossTalk/SRBDS Shows Possibility Of Leaking Information Across Physical CPU Cores.
Like AMD, older Intel CPUs did not get new microcode either, leaving the complete Core 2 Duo series unpatched. As more and more flaws hit the news, even previously patched CPUs are left behind, like the first Core i generations.

I think they should be forced to make microcode for those CPUs. Older CPUs are not bad and people continue using systems powered by them. Especially with Linux you can keep using 64-Bit systems, only 32-Bit is currently phased out, more and more every year. A pitty, but okay.

No microcode: not okay.

[Edit]: typos
_________________
Think for yourself and let others enjoy the privilege of doing so too. Voltaire


Last edited by Atha on Thu Jul 16, 2020 4:02 pm; edited 2 times in total
Back to top
View user's profile Send private message
Tony0945
Advocate
Advocate


Joined: 25 Jul 2006
Posts: 4267
Location: Illinois, USA

PostPosted: Thu Jul 16, 2020 2:00 pm    Post subject: Reply with quote

I'm sure Intel/AMD's response would be something like "These older CPU's are no longer in production. For the greatest protection buy a current production CPU."
These is analogous to Microsoft "These older OS's, XP & window 7 are no longer for sale. For the greatest protection purchase Windows 10."

At least MSFT gives a discount to current holders of Windows licenses. Intel and AMD do not.

I do see your point. At least automakers don't say "Your ten year-old-car is vulnerable to explosion in a rear end collision. For the greatest protection purchase a new {insert name} from your authorized dealer." But then there is a law requiring automobile recalls. No such law for CPU's.
Back to top
View user's profile Send private message
Atha
Apprentice
Apprentice


Joined: 22 Sep 2004
Posts: 184

PostPosted: Thu Jul 16, 2020 2:41 pm    Post subject: Reply with quote

The fact that Intel and AMD provided microcode/ucode updates for CPU around 8 years old shows that it is important. And for the systems it is not as simple as replacing the CPU, so you'd have to also replace at least the mainboard and the DIMMs, possibly more. For embedded systems and laptops it is (to 99.99%) impossible.

Most people will either leave it and live with the vulnerabilities, or they will [need|have|want] to buy a new system. But, if I personally were to buy a new system, I would go for AMD. Intel has made a bad reputation of itself lately, but it is really a decade ago (or more) when Intel misbehaved. It is only now that we see the consequences.

While I can understand that Intel and AMD abondoned some older architectures from before 2010, I think it would have been wise to at least try to provide microcode updates for at least starting from the Core i series (Intel) and the K10 (AMD) onward. And while this may be inacceptable for some companies, due to the performance impact, security may well be a top priority for others. Not to mention private customers.

So I ask you: if you had a 2012 Intel CPU running, and you had planned to keep it running because it's absolutely sufficient for your needs, and security IS a thing for you: What would you buy to replace it with? Intel or AMD?

Not only would it be great to have laws for continued support in such a case, it is IMHO also in the utter most interest of Intel – to show their customers that they can rely on the company and that it is a good idea to buy an Intel processor. Even now that AMD is clearly winning the race with its Ryzen and Threadripper – and AMD is winning without the tricks that Intel apparently used over a decade ago!
_________________
Think for yourself and let others enjoy the privilege of doing so too. Voltaire
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 46687
Location: 56N 3W

PostPosted: Thu Jul 16, 2020 3:40 pm    Post subject: Reply with quote

Atha,

You would replace it with an arm or arm64 CPU that did not offer out of order or speculative execution.
Arm is not immune to these thing either but they are less affected than x86.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
Atha
Apprentice
Apprentice


Joined: 22 Sep 2004
Posts: 184

PostPosted: Thu Jul 16, 2020 3:59 pm    Post subject: Reply with quote

Good point. I would use ARM, but I like to keep my legacy software running as well, and this happens to be DOS games (DOSBox) and Windows games (dual boot with Windows 10). I assume that some companies may have legacy installations (not games!) as well...

But thinking about it: is there an ARM64 laptop, as performant as a Ryzen laptop, with an open architecture (like UEFI or Open Firmware), with a good graphics card, good Linux support and standard connections (NVMe-PCIe, DDR4-DIMMs etc.), and all that at a price comparable to a standard laptop with FullHD display? (A friend just bought a new one after the old laptop died, it did cost around 600$...)

Because last I checked, stuff like the Librem was not having the specs and was quite expensive, even though I do find the concept intriguing. But the Librem is an Intel x86 system again...

Chromebooks? Aren't they locked in some way (firmware) into ChromeOS?
_________________
Think for yourself and let others enjoy the privilege of doing so too. Voltaire
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 46687
Location: 56N 3W

PostPosted: Thu Jul 16, 2020 5:37 pm    Post subject: Reply with quote

Atha,

My Acer R13 Chromebook runs arm64 Gentoo.
There is a special dance to get into developer mode and enable non ChromeOS booting but it is documented and you only do it once.

Arm hardware supplied with Windows has secure boot permanently enabled.
That makes booting anything else much harder, so if you want to play with Gentoo on arm64, don't start there.

Is there a Intel/Ryzen laptop that does over 12 hours on a battery charge?
Arm and x86 laptops aim at different use cases.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
Atha
Apprentice
Apprentice


Joined: 22 Sep 2004
Posts: 184

PostPosted: Thu Jul 16, 2020 6:12 pm    Post subject: Reply with quote

True. I guess I could do with a Chromebook, and I regularly look into it, but there are two things that keep me away:
  • Upgradeability. Most Chromebooks have something like 64 GB eMMC, which means it cannot be upgraded. I don't know if there are DIMM slots or if the RAM is also soldered. I say this because I do upgrade RAM and SSDs in my laptops when I find it necessary instead of purchasing a new laptop. Also I have lots and lots of files on my laptop for offline use, I don't use the cloud. Anything less then 512 GB is a nightmare for me, I normally go with 1 (at least) or 2 TB SSDs.
  • A non-reflective display. Most Chromebooks continue to have only glare displays. I hate this and will only buy a laptop with a non-glare display.

For a laptop-like Chromebook, PCIe-NVMe and DIMM slots on the mainboard, non-glare display, USB-3 and -C connectors as well as an Ethernet RJ-45 connector... I would buy it in an instant if the price isn't too high! I would even sacrafice my "legacy software" for such an ARM64 laptop...

I don't think that manufacturers think that there is a market for such a device. And I frankly don't know. I guess I'm not mainstream. Or too much mainstream, considering that there are plenty of x86 laptops with exactly those specs...
_________________
Think for yourself and let others enjoy the privilege of doing so too. Voltaire
Back to top
View user's profile Send private message
Ant P.
Watchman
Watchman


Joined: 18 Apr 2009
Posts: 6778

PostPosted: Fri Jul 17, 2020 6:43 am    Post subject: Reply with quote

Atha wrote:
There is no way to fix spec_store_bypass, the only mitigation is to disable it. This works for AMD as it does for Intel, by configuring the kernel or by using the appropriate kernel commandline parameter spec_store_bypass_disable=on, e.g. in /etc/default/grub.
/etc/default/grub:
GRUB_CMDLINE_LINUX="mitigations=auto,nosmt spec_store_bypass_disable=on"

Then you should get this:
grep . /sys/devices/system/cpu/vulnerabilities/*:
spec_store_bypass:Mitigation: Speculative Store Bypass disabled

Didn't know that. I assumed it was a no microcode thing because my zen2 seems to have that workaround by default, but I haven't done anything special to enable it.
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


Joined: 23 May 2008
Posts: 4995
Location: Dallas area

PostPosted: Fri Jul 17, 2020 9:21 am    Post subject: Reply with quote

I don't use any cmd line overrides, just the normal config switches.

Code:
$ ls *
itlb_multihit  l1tf  mds  meltdown  spec_store_bypass  spectre_v1  spectre_v2  tsx_async_abort
/sys/devices/system/cpu/vulnerabilities $ cat *
Not affected
Not affected
Not affected
Not affected
Mitigation: Speculative Store Bypass disabled via prctl and seccomp
Mitigation: usercopy/swapgs barriers and __user pointer sanitization
Vulnerable, IBPB: disabled, STIBP: disabled
Not affected

_________________
PRIME x570-pro, 3700x, RX 550 - 5.8 zen kernel
Acer E5-575 (laptop), i3-7100u - i965 - 5.5 zen kernel
---both---
gcc 9.3.0, profile 17.1 (no-pie & modified) amd64-no-multilib, eudev, openrc, openbox, palemoon
Back to top
View user's profile Send private message
Tony0945
Advocate
Advocate


Joined: 25 Jul 2006
Posts: 4267
Location: Illinois, USA

PostPosted: Fri Jul 17, 2020 11:39 am    Post subject: Reply with quote

Nor I. Grub legacy on Phenom II, reFind on Ryzen & Bulldozer

Phenom II
Code:
tony@Casti vulnerabilities $ cat *
Not affected
Not affected
Not affected
Not affected
Not affected
Mitigation: usercopy/swapgs barriers and __user pointer sanitization
Vulnerable, STIBP: disabled
Not affected
Not affected
Ryzen
Code:
#  cd /sys/devices/system/cpu/vulnerabilities
MSI /sys/devices/system/cpu/vulnerabilities # cat *
Not affected
Not affected
Not affected
Not affected
Mitigation: Speculative Store Bypass disabled via prctl and seccomp
Mitigation: usercopy/swapgs barriers and __user pointer sanitization
Vulnerable, IBPB: disabled, STIBP: disabled
Not affected
Bulldozer
Code:
Trantor vulnerabilities #  cat *
Not affected
Not affected
Not affected
Not affected
Mitigation: Speculative Store Bypass disabled via prctl and seccomp
Mitigation: usercopy/swapgs barriers and __user pointer sanitization
Vulnerable, STIBP: disabled
Not affected
This sounds HIGHLY unlikely and if the attacker is this deep into your machine , you are fscked anyway. Seems more likley on a Windows Machine blindly downloading "updates" and "fixes" from non-Microsoft sources. On a Gentoo machine wouldn't the compiler have to be infected? And the attack code built into the compiler or the kernel?
Back to top
View user's profile Send private message
Mgiese
Veteran
Veteran


Joined: 23 Mar 2005
Posts: 1501
Location: indiana

PostPosted: Fri Jul 31, 2020 8:51 am    Post subject: Reply with quote

as of now I dont use intel anymore, just upgraded to a AMD Ryzen 7 3700X and I must say I am really impressed, with kernel 5.7.2 all vulnerabilities are fixed without taking any extra care :

Code:
$ vuln
/sys/devices/system/cpu/vulnerabilities/itlb_multihit:Not affected
/sys/devices/system/cpu/vulnerabilities/l1tf:Not affected
/sys/devices/system/cpu/vulnerabilities/mds:Not affected
/sys/devices/system/cpu/vulnerabilities/meltdown:Not affected
/sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Mitigation: Speculative Store Bypass disabled via prctl and seccomp
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: usercopy/swapgs barriers and __user pointer sanitization
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full AMD retpoline, IBPB: conditional, STIBP: conditional, RSB filling
/sys/devices/system/cpu/vulnerabilities/srbds:Not affected
/sys/devices/system/cpu/vulnerabilities/tsx_async_abort:Not affected


and by the way, upgrading from simple 4 core without HT to this 16 HT core monster has a very huge impact on compile times...
_________________
I do not have a Superman complex, for I am God not Superman :D

Ryzen7 3700x ; Geforce1650 ; kernel 5.8.13
Back to top
View user's profile Send private message
Tony0945
Advocate
Advocate


Joined: 25 Jul 2006
Posts: 4267
Location: Illinois, USA

PostPosted: Fri Jul 31, 2020 1:33 pm    Post subject: Reply with quote

Mgiese wrote:
and by the way, upgrading from simple 4 core without HT to this 16 HT core monster has a very huge impact on compile times...

I went from an Athlon II X3 to Ryzen 2700X. AMAZING!
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Networking & Security All times are GMT
Goto page Previous  1, 2, 3
Page 3 of 3

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum