How to disable all countermeasures for spectre and meltdown (or any cache side-channel attacks) ?

2

2600

Hello folks,

Can anyone give us a hint on how to disable at boot time all protections for Intel CPU flaws recently discovered ?
With new exploits been invented every month I believe it is pointless to trade performance for a false sense of security.

My FreeBSD server is not connected to any network so I have nothing to fear. Don't worry, I also understand the attack could come from any code I try to run locally.

I just would like to know if there is some quick fix (like a boot load parameter) to make the kernel run as fast possible.
Please, don't bother to tell me I could be vulnerable: keep you false sense of security for yourself.

Thank you for your help.
 
In /boot/loader.conf add vm.pmap.pti=0 and hw.ibrs_disable=1. In /etc/sysctl.conf add hw.mds_disable=0.

And yes, sometimes there are valid reasons to do this. I personally do this on one of my boxes because it has an Intel Atom CPU which isn't vulnerable.
 
Thank you very much xtaz. Any documentation available on such parameters for /boot/loader.conf and /etc/sysctl.conf?
Any tutorial about performance boost on FreeBSD ? Some recommended book maybe ?

By the way, I guess Atom processors are not vulnerable because they are already slow from default. :)
 
2600 said:
By the way, I guess Atom processors are not vulnerable because they are already slow from default. :)
Click to expand...
No, because they don't do speculative execution. And it does affect way more than Intel processors; the list includes ARM, PowerPC, and so on. I think the oldest machine that is affected might be the IBM 360/91, which was the first computer to have out-of-order execution (although I'm not sure it did speculative execution), and it was the first machine to use Tomasulo's algorithm to organize it. By the way, that puts it back into the mid 1960s!

And this whole thing is not about slow, it is about information leakage. Which in certain environments is not a problem, as you said. If your computer is in an environment where unauthorized access is not possible, then information leakage is not an issue. I've worked with computer sites where every system administrator carries an assault rifle with them; in those environments, guarding against Spectre and Meltdown is much less important than guarding against bad guys that carry larger calibers.

And now my advice: Before you think about changing this configuration, consider the tradeoffs. How much performance are you really going to gain? And what are the likely side-effects? For example, it could be that by putting configuration parameters into unusual state can make the system experience unusual bugs, act weird, or cause other performance problems. If you are serious about this, you should probably do a before/after performance comparison study, and validate that the system is still reliable, and only put the change into a production environment afterwards.

Or to put it differently, never mess with a running system. Look, to administer a computer you have to hire a man and a dog. The man is there to feed the dog. The dog is there to bite the man if he tries to touch the computer.
 
ralphbsz said:
No, because they don't do speculative execution. And it does affect way more than Intel processors; the list includes ARM, PowerPC, and so on. I think the oldest machine that is affected might be the IBM 360/91, which was the first computer to have out-of-order execution (although I'm not sure it did speculative execution), and it was the first machine to use Tomasulo's algorithm to organize it. By the way, that puts it back into the mid 1960s!

And this whole thing is not about slow, it is about information leakage. Which in certain environments is not a problem, as you said. If your computer is in an environment where unauthorized access is not possible, then information leakage is not an issue. I've worked with computer sites where every system administrator carries an assault rifle with them; in those environments, guarding against Spectre and Meltdown is much less important than guarding against bad guys that carry larger calibers.

And now my advice: Before you think about changing this configuration, consider the tradeoffs. How much performance are you really going to gain? And what are the likely side-effects? For example, it could be that by putting configuration parameters into unusual state can make the system experience unusual bugs, act weird, or cause other performance problems. If you are serious about this, you should probably do a before/after performance comparison study, and validate that the system is still reliable, and only put the change into a production environment afterwards.

Or to put it differently, never mess with a running system. Look, to administer a computer you have to hire a man and a dog. The man is there to feed the dog. The dog is there to bite the man if he tries to touch the computer.
Click to expand...

Cavium ThunderX (v1) (and a few others less powerful ARMs) isn't affected buy any of those. :)

[EDIT]

Oh, and RISC-V is not affected too.
 
ralphbsz said:
No, because they don't do speculative execution. And it does affect way more than Intel processors; the list includes ARM, PowerPC, and so on. I think the oldest machine that is affected might be the IBM 360/91, which was the first computer to have out-of-order execution (although I'm not sure it did speculative execution), and it was the first machine to use Tomasulo's algorithm to organize it. By the way, that puts it back into the mid 1960s!
Click to expand...

It was supposed to be a joke, ralphbsz. They are already slow because they "don't do speculative execution" and also lack other features.
But thanks for mentioning the Tomasulo's algorithm. Now I'm curious to understand about the algorithms running on modern Intel processors.
Do you know what Intel are using nowadays ?

ralphbsz said:
And now my advice: Before you think about changing this configuration, consider the tradeoffs. How much performance are you really going to gain? And what are the likely side-effects? For example, it could be that by putting configuration parameters into unusual state can make the system experience unusual bugs, act weird, or cause other performance problems. If you are serious about this, you should probably do a before/after performance comparison study, and validate that the system is still reliable, and only put the change into a production environment afterwards.
Click to expand...

I need ALL of the performance I can squeeze out of it (and more). Also I don't see how can I put a machine in "into unusual state" just by using xtaz tips. Isn't the modern processors (and FreeBSD) supposed to run with speculative execution activated from factory ?
Anyway, thanks for reminding us about the danger of tickling our production servers without previous validations.
Don't worry, there is no server yet. We will be doing many, many tests before going live.

https://www.redhat.com/en/blog/pushing-limits-kernel-networking

http://fasterdata.es.net/host-tuning/linux/

https://software.intel.com/en-us/ar...s-for-latency-part-1-configuring-the-hardware
https://software.intel.com/en-us/ar...ations-for-latency-part-2-tuning-applications

https://docs.oracle.com/cd/E14447_01/coh.330/coh33ug/performancetuning.htm

Any other link to add to that list ?

Thank you for your reply, ralphbsz.
 
2600 said:
Now I'm curious to understand about the algorithms running on modern Intel processors.
Do you know what Intel are using nowadays ?
Click to expand...
I am not a microprocessor architect. The stuff used today is exceedingly complicated, and quite secret, since microprocessors are a competitive field. As Spectre and Meltdown have shown, having fewer vulnerabilities against side-channel attacks can be a competitive advantage. If you start web searches for Spectre and Meltdown, you will find some discussion of the underlying mechanisms; I know that one (unfortunately former) colleague of mine was heavily involved in researching this, but I don't know whether his findings have ever been published.

I need ALL of the performance I can squeeze out of it (and more). Also I don't see how can I put a machine in "into unusual state" just by using xtaz tips.
Click to expand...
What I mean by "unusual" is: If everyone, in particular the people who test (and alpha- and beta-) test FreeBSD run their machines in configuration "X", and you run it in configuration "Y", you are taking a risk of encountering bugs.

And: All performance tuning has to start by measuring. And understanding your workload. There are lots of books on performance tuning, but they tend to be a bit obsolete (computer technology moves fast), and they don't tend to go into details. My real advice would be the following: The cost of performance is very low these days, and the cost of manpower is very high. Instead of putting lots of effort into tuning things yourself, just buy more or faster CPUs. For an individual user with a small number of CPUs, that's more efficient. The game changes if you are working in place (like the FAANGs or big computer companies) where your tuning controls millions of CPUs.
 
You must log in or register to reply here.
Back
Top