91–100 of 114 posts
I don't like how these Scepter mitigations are being rolled out with no cost/benefit analysis. On a client machine, I'd rather just disable Javascript than pay a 30-50% performance penalty for mitigating these vulnerabilities.
I have been meaning to ask about this. How vulnerable are desktops to these exploits?
Earlier quoted context omitted.
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/...
I don't like how these Scepter mitigations are being rolled out with no cost/benefit analysis. On a client machine, I'd rather just disable Javascript than pay a 30-50% performance penalty for mitigating these vulnerabilities.
Earlier quoted context omitted.
: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?
Earlier quoted context omitted.
: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?
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.
Intel was supposed to have 20-30% advantage on single thread performance over Amd. Now I guess single or multiple thread AMD is better on Linux. I don't know why it makes me giddy thinking of the coming consumer wars between the 2.
If performance takes a hit by about 20% it is going to be noticeable. Next up I think people will start looking to upgrade to a faster CPU just to get back to last week's performance metrics. They might now consider AMD.
If AMD finds this affects them less they should sponsor security researchers writing proof of concept exploits to convince people that that turning off the mitigation is an absolute no-no, so it will for force people to take a performance hit and go shopping for CPUs.
I don't like how these Scepter mitigations are being rolled out with no cost/benefit analysis. On a client machine, I'd rather just disable Javascript than pay a 30-50% performance penalty for mitigating these vulnerabilities.
I have been meaning to ask about this. How vulnerable are desktops to these exploits?
I'd also personally not feel comfortable using a Windows PC, given that running unchecked 3rd-party code is sort of required to do anything with it.
Earlier quoted context omitted.
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?
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.
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.
Also the kernel flags, don't block intel microcode "improvements". You have to do this with:
sudo apt-mark hold intel-microcode
Mitigation isn't a fix, it's a bandaid.
Earlier quoted context omitted.
Somehow I doubt nuclear power plants run (unmodified) Linux kernels released in the last 5 years
Psst, every machine on the Internet must now be hardened to conform to nuclear and aerospace industry standards. So sayeth the Priesthood of Infosec. Haven't you heard?