14 ms·

This was known. https://lwn.net/Articles/765837/ https://lwn.net/Articles/765837/ reports 21% performance impact and the plan was to handle STIBP as an opt-in s

This was known. https://lwn.net/Articles/765837/ 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.

rwmj 8y ago
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.
- pixl97 8y ago
  Hey boss, I don't understand why the code works in devel but fails in production?
  - CyberShadow 8y ago
    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.
    - manquer 8y ago
      try convincing a corp sec dept in large org to sign off on disabling anywhere.
  - quickben 8y ago
    :p yes, there will be some of that around.
    - CyberShadow 8y ago
      What's an example of typical application code that will behave differently with the mitigations on or off?
      - b1r6 8y ago
        Certainly the speed of it's execution. That could be difference enough to be concerning when shifting from dev to prod.
      - rdtsc 8y ago
        > 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.
  - JadeNB 8y ago
    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?
  - chrisseaton 8y ago
    Not everyone has ‘production’. A mathematician running experiments only locally, for example.
- deleted 8y ago
  [deleted]
- crustycoder 8y ago
  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? :-(
  - rwmj 8y ago
    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/admin-guide/kernel-parameters.txt https://github.com/torvalds/linux/blob/master/Documentation/...
    - crustycoder 8y ago
      Unfortunately that list seems to be incomplete, for example nospec_store_bypass_disable or stf_barrier
  - opsroller 8y ago
    lsmod modinfo ${somemodule} man lsmod man modinfo This is elementary level linux, you should know this.
    - deleted 8y ago
      [deleted]
    - crustycoder 8y ago
      That's module flags, not kernel ones. Idiot.
  - crustycoder 8y ago
    Yay! Go Linus, Go! http://lkml.iu.edu/hypermail/linux/kernel/1811.2/01328.html http://lkml.iu.edu/hypermail/linux/kernel/1811.2/01328.html https://www.theregister.co.uk/2018/11/20/linux_kernel_spectre_v2_patch_slowdown_intel/ https://www.theregister.co.uk/2018/11/20/linux_kernel_spectr...
- int0x80 8y ago
  It makes sense (to me) and it has been discussed. I don't know what was the conclusion though.
- mulle_nat 8y ago
  I don't think you can turn off all mitigations, since the retpoline (https://stackoverflow.com/questions/48089426/what-is-a-retpoline-and-how-does-it-work 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.

rwmj 8y ago

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.

pixl97 8y ago
Hey boss, I don't understand why the code works in devel but fails in production?
- CyberShadow 8y ago
  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.
  - manquer 8y ago
    try convincing a corp sec dept in large org to sign off on disabling anywhere.
- quickben 8y ago
  :p yes, there will be some of that around.
  - CyberShadow 8y ago
    What's an example of typical application code that will behave differently with the mitigations on or off?
    - b1r6 8y ago
      Certainly the speed of it's execution. That could be difference enough to be concerning when shifting from dev to prod.
    - rdtsc 8y ago
      > 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.
- JadeNB 8y ago
  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?
- chrisseaton 8y ago
  Not everyone has ‘production’. A mathematician running experiments only locally, for example.
deleted 8y ago
[deleted]
crustycoder 8y ago
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? :-(
- rwmj 8y ago
  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/admin-guide/kernel-parameters.txt https://github.com/torvalds/linux/blob/master/Documentation/...
  - crustycoder 8y ago
    Unfortunately that list seems to be incomplete, for example nospec_store_bypass_disable or stf_barrier
- opsroller 8y ago
  lsmod modinfo ${somemodule} man lsmod man modinfo This is elementary level linux, you should know this.
  - deleted 8y ago
    [deleted]
  - crustycoder 8y ago
    That's module flags, not kernel ones. Idiot.
- crustycoder 8y ago
  Yay! Go Linus, Go! http://lkml.iu.edu/hypermail/linux/kernel/1811.2/01328.html http://lkml.iu.edu/hypermail/linux/kernel/1811.2/01328.html https://www.theregister.co.uk/2018/11/20/linux_kernel_spectre_v2_patch_slowdown_intel/ https://www.theregister.co.uk/2018/11/20/linux_kernel_spectr...
int0x80 8y ago
It makes sense (to me) and it has been discussed. I don't know what was the conclusion though.
mulle_nat 8y ago
I don't think you can turn off all mitigations, since the retpoline (https://stackoverflow.com/questions/48089426/what-is-a-retpoline-and-how-does-it-work 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.