361–370 of 378 posts
Anybody know how to disable the chicken bit on Windows? They're not planning to fix this until fucking December...
[0]: https://learn.microsoft.com/en-us/windows-hardware/drivers/d...
Earlier quoted context omitted.
Why do comments like this just make a bold claim and then wander off as if the claim stands for itself? No explanation. No insight. I mean why should we just take your word for it? I'd like to be educated here why a big switch statement wouldn't necessarily protect us from these CPU vulnerabilities? Anyone willing to help?
The question should rather be: why would it protect you? This switch statement also runs on a CPU, which is still vulnerable. This CPU still speculates the execution of the switch statement. No amount of software will make hardware irrelevant.
Earlier quoted context omitted.
The idea being that the main process and content processes should never be on the same core? I would worry about cross site leakage. From my understanding that would be unavoidable as soon as you have more tabs open than cores, which feels like an unworkable restriction. Imagine opening a 9th tab and bring told you need to upgrade your 3700X to a 3900X.
I think there's several levels. As a first step, I'd appreciate reducing the risk of javascript extracting contents from outside the browser. A second step could be to use more granular core scheduling within firefox, to prevent sharing cores that shouldn't be shared. A process/thread hierarchy can create multiple core scheduling groups.
But that means essentially reserving a core for the browser only. I don't think that would be shippable by default.
Earlier quoted context omitted.
The question should rather be: why would it protect you? This switch statement also runs on a CPU, which is still vulnerable. This CPU still speculates the execution of the switch statement. No amount of software will make hardware irrelevant.
You need certain instruction to exploit the vulnerability, if the switch statement doesn't use that then it is safe.
So, yes, the switch statemement might be safe, but you would need to prove that your switch statement doesn't use those instructions. You don't get to claim that for free just because you are using a switch-statement.
Conversely, even if you execute bare metal instructions for the user of the VM, you could also deny those instructions to the user. Eg by not allowing self-modifying code, and statically making sure that the relevant code doesn't contain those instructions.
So the switch statement by itself does not do anything for your security.
Earlier quoted context omitted.
A very bold claim with zero evidence.
What about it is very bold? The instruction sequence mentioned seems pretty reasonable and not at all out of the question for a JavaScript JIT to generate.
Earlier quoted context omitted.
So are Ryzen 5000's without Radeon not vulnerable? I guess said processors are zen 3? I have an "AMD Ryzen 9 5950x Desktop Processor" which appears to be Zen 3. I think I'm good? (Not that I'm running untrusted workloads, but yknow, fortune favors the prepared)
You are likely frequently running untrusted workloads. As javascript in a browser. I don't know about this one, but at least meltdown was fully exploitable from js. But yes, you are fine, 5950x is Zen3.
Earlier quoted context omitted.
Cloudflare blog also mentions javascript https://blog.cloudflare.com/zenbleed-vulnerability/
Might just be parroting the claim from this thread, though.
Earlier quoted context omitted.
> you're running instructions on the actual CPU Just how many times is the average operating system workload (with or without a virtual machine also running a second average operating system workload) context switching a second? Like... unless I'm wrong... the kernel is the main process, and then it slices up processes/threads, and each time those run, they have their own EAX/EBX/ECX/ESP/EBP/EIP/etc. (I know it's RAX…
Usually a few hundred to a few thousand times a second.
For anyone interested in seeing this on the nearest Linux box:
vmstat -S M 1
The README in the tar file with the exploit (linked at "If you want to test the exploit, the code is available here") contains some more details, including a timeline: - `2023-05-09` A component of our CPU validation pipeline generates an anomalous result. - `2023-05-12` We successfully isolate and reproduce the issue. Investigation continues. - `2023-05-14` We are now aware of the scope and severity of the issue. -…
Something is a little unclear to me. Does https://archlinux.org/packages/core/any/amd-ucode/ amd-ucode 20230625.ee91452d-5 last updated 2023-07-25 11:48 UTC Contains the microcode update that addresses this? https://git.kernel.org/pub/scm/linux/kernel/git/firmware/lin... says that the fixed version is 2023-07-18, but the amd-ucode version in Arch is 20230625.. but it was last updated in 2023-07-25.. My guess is that…
Either way, as noted elsewhere in the comments, only the Rome CPU series has received updated microcode with fixes. All other Zen 2 users need the fix that was released as part of Linux 6.4.6: https://lwn.net/Articles/939102/
(which has been built and packaged for Arch)