Home
12 comments
nomercy4003 months ago
Wow, so providing a tool for bypassing the protection mechanism of a device (cpu) is accepted when it comes from google?<p>Try this on any game console or drm protected device ans you are DMCAed before you know it.
评论 #43279858 未加载
评论 #43280860 未加载
评论 #43279068 未加载
评论 #43278703 未加载
评论 #43279309 未加载
评论 #43281156 未加载
评论 #43278626 未加载
评论 #43277632 未加载
dzdt3 months ago
The blog post that explains the exploit and how this whole thing works is at <a href="https://bughunters.google.com/blog/5424842357473280/zen-and-the-art-of-microcode-hacking" rel="nofollow">https://bughunters.google.com/blog/5424842357473280/zen-and-...</a>
评论 #43274618 未加载
评论 #43276509 未加载
transpute3 months ago
This is not the first case of accidental reuse of example keys in firmware signing, <a href="https://kb.cert.org/vuls/id/455367" rel="nofollow">https://kb.cert.org/vuls/id/455367</a><p>Would it be useful to have a public list of all example keys that could be accidentally used, which could be CI/CD tested on all publicly released firmware and microcode updates?<p>If there was a public test suite, Linux fwupd and Windows Update could use it for binary screening before new firmware updates are accepted for distribution to endpoints.
评论 #43275798 未加载
评论 #43279298 未加载
BonusPlay3 months ago
Both AMD and Google note, that Zen[1-4] are affected, but what changed about Zen5? According to the timeline, it released before Google notified AMD [1].<p>Is it using different keys, but same scheme (and could possibly be broken via side-channels as noted in the article)? Or perhaps AMD notices something and changed up the microcode? Some clarification on that part would be nice.<p>[1] <a href="https://github.com/google/security-research/security/advisories/GHSA-4xq7-4mgh-gp6w">https://github.com/google/security-research/security/advisor...</a>
评论 #43277487 未加载
dtgriscom3 months ago
Are there any examples of using this for non-nefarious reasons? For instance, could I add new instructions that made some specific calculation faster?
评论 #43277510 未加载
评论 #43277752 未加载
评论 #43287493 未加载
nomercy4003 months ago
Doesn't changing how your cpu's microcode works mean you can bypass or leak all kinds of security measures and secrets?
评论 #43277919 未加载
amluto3 months ago
Something worth noting:<p>CPUs have no non-volatile memory -- microcode fully resets when the power is cycled. So, in a sensible world, the impact of this bug would be limited to people temporarily compromising systems on which they already had CPL0 (kernel) access. This would break (possibly very severely and maybe even unpatchably) SEV, and maybe it would break TPM-based security if it persisted across a soft reboot, but would not do much else of consequence.<p>But we do not live in a sensible world. The entire UEFI and Secure Boot ecosystem is a complete dumpster fire in which the CPU, via mechanisms that are so baroque that they should have been disposed of in, well, the baroque era, enforces its own firmware security instead of delegating to an independent coprocessor. So the actual impact is that getting CPL0 access to an unpatched system [0] will allow a complete compromise of the system flash, which will almost certainly allow a permanent, irreversible compromise of that system, including persistent installation of malicious microcode that will pretend to be patched. <i>Maybe</i> a really nice Verified Boot (or whatever AMD calls its version) implementation would make this harder. Maybe not.<p>(Okay, it's not irreversible if someone physically rewrites the flash using external hardware. Good luck.)<p>[0] For this purpose, "unpatched" means running un-fixed microcode at the time at which CPL0 access is gained.
评论 #43276338 未加载
评论 #43275976 未加载
nullc3 months ago
I wonder if this can be used to figure out what code is running on the PSP?
junon3 months ago
Random off topic question: could one theoretically (with infinite time and resources) write new microcode firmware for a modern processor that turns it into an armv8+ processor?
评论 #43281727 未加载
评论 #43282908 未加载
评论 #43281733 未加载
评论 #43281857 未加载
评论 #43281503 未加载
mkj3 months ago
Was the microcode signing scheme documented by AMD, or did the researchers have to reverse engineer it somehow? I couldn't see a mention in the blog post.
评论 #43274355 未加载
p1mrx3 months ago
> You can use the `resign` command to compensate for the changes you made:<p>How does that work? Did someone figure out AMD's private keys?
评论 #43273684 未加载
评论 #43273757 未加载
Julesman3 months ago
I wonder if anyone involved could define 'zen.' I know the answer.