Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zentool – AMD Zen Microcode Manipulation Utility

github.com

Post reply on HN
Print view View original

41–50 of 69 posts

Re: Zentool – AMD Zen Microcode Manipulation Utility

#41

Post by the8472 »

transpute wrote: post #14

This is not the first case of accidental reuse of example keys in firmware signing, https://kb.cert.org/vuls/id/455367 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? If there was a public test suite, Linux fwupd and Windows Update could use it for binary screening before new firmware upd…

It doesn't really fix the underlying "didn't hire a qualified cryptographer" issue. By the time a third party scanning finds it in a released firmware millions of chips will already have been produced.

Plus it would only help with that one issue, not with the millions of other ways things can go wrong. Vendors publishing their security architecture so others can convince themselves that it is in fact secure would be better, it is how TLS or WPA get enough eyeballs.

Re: Zentool – AMD Zen Microcode Manipulation Utility

#42

Post by BSDobelix »

nomercy400 wrote: post #28

Wow, so providing a tool for bypassing the protection mechanism of a device (cpu) is accepted when it comes from google? Try this on any game console or drm protected device ans you are DMCAed before you know it.

What a sad and anti-hacker mentality comment.

Re: Zentool – AMD Zen Microcode Manipulation Utility

#43

Post by rft »

nomercy400 wrote: post #28

Wow, so providing a tool for bypassing the protection mechanism of a device (cpu) is accepted when it comes from google? Try this on any game console or drm protected device ans you are DMCAed before you know it.

We broke the "encryption" (more like scrambling) of the AMD K8 and K10 CPU microcode updates. We released tooling to write and apply your own microcode updates. AMD did not take any actions against us. Granted, this was a university project so we clearly were within the academic context, but we were in no way affiliated with a too big to sue company.

https://www.usenix.org/system/files/conference/usenixsecurit...

https://informatik.rub.de/veroeffentlichungenbkp/syssec/vero...

https://github.com/RUB-SysSec/Microcode

Re: Zentool – AMD Zen Microcode Manipulation Utility

#44

Post by dzdt »

rft wrote: post #43
nomercy400 wrote: post #28

Wow, so providing a tool for bypassing the protection mechanism of a device (cpu) is accepted when it comes from google? Try this on any game console or drm protected device ans you are DMCAed before you know it.

We broke the "encryption" (more like scrambling) of the AMD K8 and K10 CPU microcode updates. We released tooling to write and apply your own microcode updates. AMD did not take any actions against us. Granted, this was a university project so we clearly were within the academic context, but we were in no way affiliated with a too big to sue company. https://www.usenix.org/system/files/conference/usenixsecurit... htt…

How much is there in common between the Zen cpus of the current microcode reverse-engineering compared to the K8/K10 you looked at?

Re: Zentool – AMD Zen Microcode Manipulation Utility

#45

Post by crest »

nomercy400 wrote: post #28

Wow, so providing a tool for bypassing the protection mechanism of a device (cpu) is accepted when it comes from google? Try this on any game console or drm protected device ans you are DMCAed before you know it.

Any encryption/signature that can be broken in software on affordable hardware is just that: BROKEN.

What is your theory of harm? Who is harmed and how? Why should the law protect them by restricting the freedom of others?

AMD *sold* these CPUs to customers potentially running this tool on their hardware. That makes you think AMD should be entitled to restrict what the public is allowed to know about their products or does with them post sale?

Also if AMD is still in control shouldn't they be liable too? Should users get to sue AMD if an AMD CPU got compromised by malware e.g. the next side channel attack?

I might start to feel some sympathy for AMD and Intel if they voluntary paid all their customers for the effective post-sale performance downgrades inflicted on customers by mitigations required to make their CPUs fit for purpose.

Re: Zentool – AMD Zen Microcode Manipulation Utility

#46

Post by garaetjjte »

taviso wrote: post #5
yuriks wrote: post #4

Earlier quoted context omitted.

The intro document mentions > Here's the thing - the big vendors encrypt and sign their updates so that you cannot run your own microcode. A big discovery recently means that the authentication scheme is a lot weaker than intended, and you can now effectively "jailbreak" your CPU! But there's no further details. I'd love to know about the specifics too!

They accidentally used the example key from AES-CMAC RFC, the full details are in the accompanying blog post: https://bughunters.google.com/blog/5424842357473280/zen-and-...

I suppose the reuse wasn't accidental, but they mistakenly thought the key doesn't matter for CMAC.

Re: Zentool – AMD Zen Microcode Manipulation Utility

#47

Post by rft »

dzdt wrote: post #44
rft wrote: post #43

Earlier quoted context omitted.

We broke the "encryption" (more like scrambling) of the AMD K8 and K10 CPU microcode updates. We released tooling to write and apply your own microcode updates. AMD did not take any actions against us. Granted, this was a university project so we clearly were within the academic context, but we were in no way affiliated with a too big to sue company. https://www.usenix.org/system/files/conference/usenixsecurit... htt…

How much is there in common between the Zen cpus of the current microcode reverse-engineering compared to the K8/K10 you looked at?

I have not looked at the format of the microcode yet, so this is only based on the blog post and discussions. K8 and K10 were based on Risc86 just like Zen seems to be. There also are some parallels, especially when it comes to sequence words and branch delay slots. There are also major differences like moving from triads to quads. I assume there are quite some similarities, but the current authors are better qualified to answer this at this point.

Re: Zentool – AMD Zen Microcode Manipulation Utility

#48

Post by mrb »

nomercy400 wrote: post #28

Wow, so providing a tool for bypassing the protection mechanism of a device (cpu) is accepted when it comes from google? Try this on any game console or drm protected device ans you are DMCAed before you know it.

It's not who releases it, it's who is the target that makes the difference. AMD chooses not to sue the researchers, whereas a game console maker would probably sue.

Re: Zentool – AMD Zen Microcode Manipulation Utility

#49

Post by amluto »

sirdarckcat wrote: post #33
amluto wrote: post #20

Earlier quoted context omitted.

This probably depends on a lot of non-public info: how does the PSP validate CPU state? where does PSP firmware come from? can the PSP distinguish between a CPU state as reported by honest ucode and that state as reported by the CPU running malicious ucode? I think that, at least on Intel, the “microcode” package includes all kinds of stuff beyond just the actual CPU microcode, and I think it’s all signed together. I…

> This probably depends on a lot of non-public info: how does the PSP validate CPU state? https://github.com/amd/AMD-ASPFW/blob/3ca6650dd35d878b3fcbe5...

That seems to be reading a memory mapped register per core. I wonder what backs that register.
Post reply on HN