Hacker News Reader

Comment by bonzini | Hacker News Reader

This was known. https://lwn.net/Articles/765837/ reports 21% performance impact and the plan was to handle STIBP as an opt-in security feature. I am not sure why that was not furthered in the patches that have actually been committed to Linux, as I did not follow them closely.

View on HN

Apparently the way to turn this and other mitigations off is the following mouthful:

    pti=off spectre_v2=off l1tf=off nospec_store_bypass_disable no_stf_barrier

Would it make sense to have a single flag to "run insecure but fast" that we can use on pure development machines, test servers and the like? My Intel development server only runs code I choose.

Hey boss, I don't understand why the code works in devel but fails in production?

You're implying (with unnecessary snark) that:

1. Development machines should be configured identically to production machines. (Do you install a GUI and development tools on your production servers?) Occasional differences in behavior between development/production are par for the course, and is why staging environments are commonly used.

2. The mitigations affect the execution result of code likely to be developed/executed at a typical software shop. AFAIU the attacks are timing-based, and won't affect valid code that's not specifically looking to exploit them.

try convincing a corp sec dept in large org to sign off on disabling anywhere.

:p yes, there will be some of that around.

What's an example of typical application code that will behave differently with the mitigations on or off?

Certainly the speed of it's execution. That could be difference enough to be concerning when shifting from dev to prod.

> What's an example of typical application code that will behave differently with the mitigations on or off?

Pretty much any application where there is limited execution time budget. If it takes too long it's considered broken, unusable, undesirable etc. Any realtime-ish stuff.

Ad bidding, video processing, audio processing / messaging, industrial control systems, robotics, general signal processing, logging systems that will now be overwhelmed and drop messages, databases that will experience timeouts and retries, scientific computations that will now take weeks more to run and potentially screw up other projects.

But hey it's a great time for Intel. Hey, psst, over here, I got a faster later gen CPU for you, for an easy price of $999.99 to bring you performance back to where it was last week.

Surely that objection applies to being able to turn off mitigation at all, not to whether the invocation that does so is short or (as currently) long?

Not everyone has ‘production’. A mathematician running experiments only locally, for example.

This alphabetti spaghetti of boot flags is getting ridiculous, there seems to be no central list anywhere, just random snippets across the web. Why is there not a Linus rant when you really need one? :-(

To be fair there is a list, although as you say the flags themselves are pretty random. Of course they can't be easily changed because that would break everyone's boot environment.

https://github.com/torvalds/linux/blob/master/Documentation/...

lsmod

modinfo ${somemodule}

man lsmod man modinfo

This is elementary level linux, you should know this.

It makes sense (to me) and it has been discussed. I don't know what was the conclusion though.

I don't think you can turn off all mitigations, since the retpoline (https://stackoverflow.com/questions/48089426/what-is-a-retpo...) stuff is generated by the compiler. You'd probably need to recompile the kernel. How much retpoline is responsible for the performance hit, I don't know.

Also the kernel flags, don't block intel microcode "improvements". You have to do this with:

  sudo apt-mark hold intel-microcode

and look for what's currently installed.

Mitigation isn't a fix, it's a bandaid.

Reply on news.ycombinator.com