71–80 of 114 posts
This is somewhat unfortunate for older-gen hardware. The difference between chugging-along but usable vs 20% reduced performance is crippling.
Earlier quoted context omitted.
Sorry, but that's my call, not yours. My computer is not a nuclear power plant.
The Linux team also needs to make a call on the kernel they maintain. You can always choose to stick with an older kernel or even patch out the fixes if you like.
Earlier quoted context omitted.
Someone once had the great idea that drivers should be in the same codebase as the kernel. Crazy, I know.
It doesn’t seem crazy to me that something that runs in kernel mode and uses kernel APIs should be in the kernel codebase. What are the downsides?
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?
Earlier quoted context omitted.
Someone once had the great idea that drivers should be in the same codebase as the kernel. Crazy, I know.
It doesn’t seem crazy to me that something that runs in kernel mode and uses kernel APIs should be in the kernel codebase. What are the downsides?
Earlier quoted context omitted.
They still sell Itanian, I don’t think Spectre/Meltdown affect that product line.
*Itanium, and they would likely suffer from the same attacks (maybe not due to being a completely different architecture, but being from thw same company, not sure if there isn't crosspolination between the two), but dont think anyone has looked at them due to small market pressense.
A little Googling found an analysis from someone more knowledgeable than myself that backs this up: https://secure64.com/not-vulnerable-intel-itanium-secure64-s...
tl;dr Meltdown takes advantage of out-of-order execution, which Itanium simply doesn't have. Spectre makes use of speculative execution, which Itanium only has in a version too limited to support the attack.
I'm not an expert in this field so I can't attest to the credibility of this analysis. The Spectre part in particular sounds a little hand-wavy but it might just be over my head. But it aligns with my intuition, which is that the simpler and more explicit architecture doesn't have as many places where data can accidentally end up.
Earlier quoted context omitted.
It doesn’t seem crazy to me that something that runs in kernel mode and uses kernel APIs should be in the kernel codebase. What are the downsides?
Why should drivers necessarily run in the kernel? With appropriate abstraction for interrupts, DMA, etc. much of the work could be done in userland.
The question I was responding to was: “accepting that, rightly or wrongly, Linux drivers run in kernel mode, does it make sense for them to be in the source tree?”
In case people don't like the headline style (leaving out the reference to the answer), the answer given at the end of the article is new Spectre mitigations. We new that speculative-execution mitigations would sometimes reduce performance, and evidently they do. :-(
And yet, surprisingly, no references to " 420 " being an appropriate number for slow response time.
1.3-1.4x slowdown is a lot more than I expected (I know it's for synthetic benchmarks but still...) Can someone explain (or link to an article) how a tweak to HT branch prediction heuristic can have such a huge impact on performance?
I can test it once I get the new firmware.