61–69 of 69 posts
Earlier quoted context omitted.
Hopefully RISC-V changes things a bit.
RISC-V wouldn’t help here at all. There’s nothing about RISC-V that prevents a CPU manufacturer putting in custom instructions and not documenting them.
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 o…
Earlier quoted context omitted.
> 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.
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-...
They didn’t need a keyed hash at all, they needed a collision resistant hash.
SHA256 would have eliminated this vuln and it has a hardcoded “key” built into it.
Using a secret key for CMAC would not have been more secure, it would have just meant sophisticated hardware extraction of the key was required before this attack could be mounted.
Are there any examples of using this for non-nefarious reasons? For instance, could I add new instructions that made some specific calculation faster?
CPU vendors typically gain performance when adding new instructions because they add new fancy uops. For example, x86 has AES instructions which lead to uops which (I imagine) exercise some hardware AES block. Vendors are not simply implementing AES in pure ucode as this wouldn't really gain any performance advantage over doing AES directly in software.
Earlier quoted context omitted.
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 o…
DMCA 1201 says ANY decryption without permission from a copyright holder (with some exceptions that are in practice pretty minor) is a federal crime. Yet one more on the pile of "three felonies a day" to hold over the masses to keep them in line.
Earlier quoted context omitted.
DMCA 1201 says ANY decryption without permission from a copyright holder (with some exceptions that are in practice pretty minor) is a federal crime. Yet one more on the pile of "three felonies a day" to hold over the masses to keep them in line.
If this was the case, reading your comment (when delivered over TLS in a relevant jurisdiction) would be one such crime.
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…
Even without supposed goodwill of AMD and seeing things a different way being a) affiliated with a university b) outside the USA may have changed some of the equation.
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.
Are you talking about legalities? AFAIK Hardware jailbreaking/homebrew tools are fine even in jurisdictions blighted with with DMCA unless they're specifically for circumventing DRM. If more about morals, generally publishing vulnerability research tooling is business as usual for white hat vulnerability researchers, working at bigcorps or not, and has a long history. seems surprising to see this kind of "not cool" c…
Certain Japanese video-game companies would take issue with that interpretation of facts. Of course there is the arbitrary distinction between 'access' and 'copy' control mechanisms. Something arguably made irrelevant by the further integration of general concepts from personal-computing into certain video-game systems.