Personal computing discussed
Moderators: renee, Flying Fox, morphine
A fundamental design flaw in Intel's processor chips has forced a significant redesign of the Linux and Windows kernels to defang the chip-level security bug.
Programmers are scrambling to overhaul the open-source Linux kernel's virtual memory system. Meanwhile, Microsoft is expected to publicly introduce the necessary changes to its Windows operating system in this month's Patch Tuesday: these changes were seeded to beta testers running fast-ring Windows Insider builds in November and December.
Crucially, these updates to both Linux and Windows will incur a performance hit on Intel products. The effects are still being benchmarked, however we're looking at a ballpark figure of five to 30 per cent slow down, depending on the task and the processor model. More recent Intel chips have features – specifically, PCID – to reduce the performance hit.
Ninjitsu wrote:Cites: https://www.theregister.co.uk/2018/01/0 ... sign_flaw/More recent Intel chips have features – specifically, PCID – to reduce the performance hit.
Dave Hansen wrote:tl;dr:
KAISER makes it harder to defeat KASLR, but makes syscalls and interrupts slower. These patches are based on work from a team at Graz University of Technology posted here[1]. The major addition is support for Intel PCIDs which builds on top of Andy Lutomorski's PCID work merged for 4.14. PCIDs make KAISER's overhead very reasonable for a wide variety of use cases.
Dave Hansen wrote:Process
Context IDentifiers (PCIDs) are used to to[sic] ensure that the TLB is not flushed when switching between page tables, which makes syscalls roughly 2x faster than without it.
Dave Hansen wrote:To give folks an idea what the performance impact is like, I took the following test and ran it single-threaded:
https://github.com/antonblanchard/will- ... s/lseek1.c
It's a pretty quick syscall so this shows how much KAISER slows down syscalls (and how much PCIDs help). The units here are lseeks/second:
no kaiser: 5.2M
kaiser+ pcid: 3.0M
kaiser+nopcid: 2.2M
"nopcid" is literally with the "nopcid" command-line option which turns PCIDs off entirely.
pti=off
nopti
just brew it! wrote:How big a deal this is for my employer will depend on what the underlying vulnerability is. Really wish there was more info available so we could gauge how screwed (or not) we are, and plan accordingly. At least it should only affect a subset of our workloads, since we're (usually) not CPU-bound.
For me personally it's basically a non-issue; my home desktop and server run AMD CPUs (which apparently are unaffected), and I probably wouldn't notice the performance hit on my Intel-based laptop since I don't tend to use it for CPU-intensive stuff anyway.
Ryu Connor wrote:It is my interpretation that these are nation state or organized crime level attacks. I can see why hosts of virtualization platforms would want these leaks to bypass KASLR closed. I see less reason for the average end users to be concerned by it.
chuckula wrote:For some context about OMG IT'S THE END OF THE WORLD... some synthetic Linux benchmarks showed some hits although the real-world tests like a kernel compile run and x264/FFMPEG encoding were basically unchanged:
https://www.phoronix.com/scan.php?page= ... 6pti&num=1
As for the world of games.... zero change (the post bug-fix even wins by tiny margins in some tests): https://www.phoronix.com/scan.php?page= ... ming-Tests
just brew it! wrote:chuckula wrote:For some context about OMG IT'S THE END OF THE WORLD... some synthetic Linux benchmarks showed some hits although the real-world tests like a kernel compile run and x264/FFMPEG encoding were basically unchanged:
https://www.phoronix.com/scan.php?page= ... 6pti&num=1
As for the world of games.... zero change (the post bug-fix even wins by tiny margins in some tests): https://www.phoronix.com/scan.php?page= ... ming-Tests
I think you must have looked at the wrong chart or something; compile test shows a ~15% hit.
chuckula wrote:just brew it! wrote:chuckula wrote:For some context about OMG IT'S THE END OF THE WORLD... some synthetic Linux benchmarks showed some hits although the real-world tests like a kernel compile run and x264/FFMPEG encoding were basically unchanged:
https://www.phoronix.com/scan.php?page= ... 6pti&num=1
As for the world of games.... zero change (the post bug-fix even wins by tiny margins in some tests): https://www.phoronix.com/scan.php?page= ... ming-Tests
I think you must have looked at the wrong chart or something; compile test shows a ~15% hit.
No, I'm right. I was talking about the timed linux kernel compilation test. "Compilebench" is yet another synthetic benchmark.
mudcore wrote:Are we trying to downplay this because it doesn't seem like it will impact the typical user that cares about gaming benchmarks or? Seems like this could be pretty serious for things such as web servers. Those PostgreSQL numbers are also not exactly heart warming.
DancinJack wrote:mudcore wrote:Are we trying to downplay this because it doesn't seem like it will impact the typical user that cares about gaming benchmarks or? Seems like this could be pretty serious for things such as web servers. Those PostgreSQL numbers are also not exactly heart warming.
Isn't that what this thread has been saying?
mudcore wrote:Sorry, I guess I'm mainly taking issue with chuckula's phrasing and presentation of "typical" workloads. No its not the end of the world but this bug looks like it could have a rather significant performance impact on the majority of the web and database servers of the world. That's kinda huge... right?
Ninjitsu wrote:
Kougar wrote:If the speculative code execution is the problem, then disabling it outright will permanently affect performance.
Kougar wrote:And AMD wouldn't be affected because Ryzen doesn't perform speculative code execution to boost general performance.
jihadjoe wrote:Do you guys think a proper fix to the silicon will make it to Ice Lake?
adampk17 wrote:jihadjoe wrote:Do you guys think a proper fix to the silicon will make it to Ice Lake?
My uneducated guess is that Intel would not release a new processor that still had this errata.
fyo wrote:Note that the Phoronix benchmarks are not "clean" and include a bunch of updates, not just the Intel PTI bug fix. Theoretically, we could have all sorts of performance improvements that are masking some of the effects of the bug fix. It's likely that any such effect is very small, but we just don't know and benchmarking has a way of hitting corner cases.
fyo wrote:As for "real users" being affected, I'm not a gamer and I have a number of systems that are IO limited in one way or another. Thankfully, my file server is on an ARM system, so it should be unaffected, but I do have a couple database-bottlenecked systems and an Intel-based, ISP-provided crappy box that is also IO bound in a myriad of ways (running Intel + Windows). If the latter is hit with a 20% performance hit, it will quite frankly become unusable.
SSD systems could also experience a significant hit when swapping, which would also hurt me in some rare situations and might (finally) push me to upgrade some memory.