So, yet another secret leaking vulnerability found in a CPU (of the type I usually buy):

https://www.theregister.com/2023/07/24/amd_zenbleed_bug

The bug essentially is a flag that "marks" a register in an indeterminate state as "zero" - ie, just write over it. But if you read, it can have anything there, even such things as the passwords and encryption secrets of, for example, your SSL connection to a website.

In the idiom of the Go language, it is almost the greatest, most verboten sin of all, to allocate memory and not zero it. Every allocation in Go starts with zeroing before the program could possibly be reading it.

It would not be possible to directly exploit this vulnerability with a standard Go program. It would require bypassing it using `unsafe` or assembler code.

For other languages, memory allocation often will be allowing whatever state the memory is in when freed to be readable by a program. This is also why Go idiom recommends making use of the zero, because, it's going to run anyway, the runtime enforces it.

It does rather seem to me though, that a proactive variant would have programs deliberately zero their memory. Like, to just assume the worst in all cases, zero memory out, zero memory in.