Has anyone ever updated their CPU microcodes to run the latest instructions sets? I know that you can spoof CPUID in VM, but what about updating the microcode on the CPU itself?
Is it too complex of a task currently?
>>52236336
That's not how it works.
Good luck finding a verifiable sub-sector GDI manipulator with hash 12 sprites.
I don think that's even technically possible
Highly related: https://wiki.archlinux.org/index.php/Microcode#Enabling_Intel_microcode_updates
>>52236398
I coded my own sub instructor chain with a reverse python backdoor.
It's easy anon, if I can do it you can too.
>>52236511
This. My cpu has not received an update since 2013 unfortunately :^(
Did a bit of search.
Microcodes are heavily encrypted and kept secret and has digital signature that must match before it can be used . What little is availble to users/oem is done as a temporary patch via some type of cache (kept powered by battery).
Probably won't ever be done in any effective way until we can get more info from intel/amd or a leaker from intel/amd shares the secret.
>>52236787
So then the reason Assembly got forked so hard is because different processor families encrypted their microcode instruction sets? Interesting.
>>52236787
Open hardware when.
AMD does the same I suppose?
>>52236973
when glorious RISC-V gets picked up by someone who knows microprocessors and pipelines and manufacturing are open and possible for small tech companies/ rich individuals.
I.e. never
>>52236787
I assume this isn't the case for ARM given that it is a RISC processor
Am I correct?
>microcodes encryption are hacked and reverse engineered
>old 2600k gets newest instruction set, HEVC
>it lives on for another 10 years
>intel bankrupts itself
kek
