8 ms·

> The new runtime/secret package lets you run a function in secret mode. After the function finishes, it immediately erases (zeroes out) the registers and stack

by maxloh 11mo ago

> The new runtime/secret package lets you run a function in secret mode. After the function finishes, it immediately erases (zeroes out) the registers and stack it used. I don't understand. Why do you need it in a garbage-collected language? My impression was that you are not able to access any register in these language. It is handled by the compiler instead.

er4hn 11mo ago
In theory it prevents failures of the allocator that would allow reading uninitialized memory, which isn't really a thing in Go. In practice it provides a straightforward path to complying with government crypto certification requirements like FIPS 140 that were written with languages in mind where this is an issue.
kittywantsbacon 11mo ago
This would potentially protect against other process reading memory via some system compromise - they would be able to get new secrets but not old ones.
jerf 11mo ago
This is about minimizing attack surface. Not only could secrets be leaked by hacking the OS process somehow to perform arbitrary reads on the memory space and send keys somewhere, they could also be leaked with root access to the machine running the process, root access to the virtualization layer, via other things like rowhammering potentially from an untrusted process in an entirely different virtual context running on the same machine, and at the really high end, attacks where the government agents siezing your machine physically freeze your RAM (that is, reduce the physical temperature of your RAM to very low temperatures) when they confiscate your machine and read it out later. (I don't know if that is still possible with modern RAM, but even if it isn't I wouldn't care to bet much on the proposition that they don't have some other way to read RAM contents out if they really, really want to.) This isn't even intended as a complete list of the possibilities, just more than enough to justify the idea that in very high security environments there's a variety of threats that come from leaving things in RAM longer than you absolutely need to. You can't avoid having things in RAM to operate on them but you can ensure they are as transient as possible to minimize the attack window. If you are concerned about secrets being zeroed out in almost any language, you need some sort of support for it. Non-GC'd languages are prone to optimize away zeroing out of memory before deallocation, because under normal circumstances a write to a value just before deallocation that is never effectfully read can be dropped without visible consequence to the rest of the program. And as compilers get smarter it can be harder to fool them with code, like, simply reading afterwards with no further visible effect might have been enough to fool 20th century compilers but nowadays I wouldn't count on my compiler being that stupid. There are also plenty of languages where you may want to use values that are immutable within the context of the language, so there isn't even a way to express "let's zero out this RAM". Basically, if you don't build this in as a language feature, you have a whole lot of pressures constantly pushing you in the other direction, because why wouldn't you want to avoid the cost of zeroing memory if you can? All kinds of reasons to try to avoid that.
kbolino 11mo ago
Go has both assembly language and unsafe pointer operations available. While any uses of these more advanced techniques should be vetted before going to production, they are obviously able to break out of any sandboxing that you might otherwise think a garbage collector provides. And any language which can call C code that is resident in the same virtual memory space can have its own restrictions bypassed by said C code. This even applies to more restrictive runtimes like the JVM or Python.
vlovich123 11mo ago
Go is not a memory safe language. Even in memory safe languages, memory safety vulnerabilities can exist. Such vulnerabilities can be used to hijack your process into running untrusted code. Or as others point out sibling processes could attack yours. This underlying principle is defense in depth - you make add another layer of protection that has to be bypassed to achieve an exploit. All the chains combined raise the expense of hacking a system.
- tptacek 11mo ago
  Respectfully, this has become a message board canard. Go is absolutely a memory safe language. The problem is that "memory safe", in its most common usage, is a term of art, meaning "resilient against memory corruption exploits stemming from bounds checking, pointer provenance, uninitialized variables, type confusion and memory lifecycle issues". To say that Go isn't memory safe under that definition is a "big if true" claim, as it implies that many other mainstream languages commonly regarded as memory safe aren't. Since "safety" is an encompassing term, it's easy to find more rigorous definitions of the term that Go would flunk; for instance, it relies on explicit synchronization for shared memory variables. People aren't wrong for calling out that other languages have stronger correctness stories, especially regarding concurrency. But they are wrong for extending those claims to "Go isn't memory safe". https://www.memorysafety.org/docs/memory-safety/ https://www.memorysafety.org/docs/memory-safety/
  - vlovich123 11mo ago
    I’m not aware of any definition of memory safety that allows for segfaults- by definition those are an indication of not being memory safe. It is true that go is only memory unsafe in a specific scenario, but such things aren’t possible in true memory safe languages like c# or Java. That it only occurs in multithreaded scenarios matters little especially since concurrency is a huge selling point of the language and baked in. Java can have data races, but those data races cannot be directly exploited into memory safety issues like you can with Go. I’m tired of Go fans treating memory safety as some continuum just because there are many specific classes of how memory safety can be violated and Go protecting against most is somehow the same as protecting against all (which is what being a memory safe language means whether you like it or not). I’m not aware of any other major language claiming memory safety that is susceptible to segfaults. https://www.ralfj.de/blog/2025/07/24/memory-safety.html https://www.ralfj.de/blog/2025/07/24/memory-safety.html
hamburglar 11mo ago
The Go runtime may not be the only thing reading your process’ memory.
gethly 11mo ago
Yeah, I can hardly disagree with that sentiment myself.
tracker1 10mo ago
That's kind of the point of making it (relatively easily) accessibly... in order to ensure that secrets are wiped from memory as quickly as reasonable. This reduces a lot of potential surface area for potential attack. I used to not really see the need for this level of detail on things... then you see useful (IE in the wild exploits) for even complex factors like CPU branch prediction (for a while now), and the need starts to become much more clear.

by maxloh 11mo ago

er4hn 11mo ago

In theory it prevents failures of the allocator that would allow reading uninitialized memory, which isn't really a thing in Go. In practice it provides a straightforward path to complying with government crypto certification requirements like FIPS 140 that were written with languages in mind where this is an issue.

kittywantsbacon 11mo ago

This would potentially protect against other process reading memory via some system compromise - they would be able to get new secrets but not old ones.

jerf 11mo ago

This is about minimizing attack surface. Not only could secrets be leaked by hacking the OS process somehow to perform arbitrary reads on the memory space and send keys somewhere, they could also be leaked with root access to the machine running the process, root access to the virtualization layer, via other things like rowhammering potentially from an untrusted process in an entirely different virtual context running on the same machine, and at the really high end, attacks where the government agents siezing your machine physically freeze your RAM (that is, reduce the physical temperature of your RAM to very low temperatures) when they confiscate your machine and read it out later. (I don't know if that is still possible with modern RAM, but even if it isn't I wouldn't care to bet much on the proposition that they don't have some other way to read RAM contents out if they really, really want to.) This isn't even intended as a complete list of the possibilities, just more than enough to justify the idea that in very high security environments there's a variety of threats that come from leaving things in RAM longer than you absolutely need to. You can't avoid having things in RAM to operate on them but you can ensure they are as transient as possible to minimize the attack window. If you are concerned about secrets being zeroed out in almost any language, you need some sort of support for it. Non-GC'd languages are prone to optimize away zeroing out of memory before deallocation, because under normal circumstances a write to a value just before deallocation that is never effectfully read can be dropped without visible consequence to the rest of the program. And as compilers get smarter it can be harder to fool them with code, like, simply reading afterwards with no further visible effect might have been enough to fool 20th century compilers but nowadays I wouldn't count on my compiler being that stupid. There are also plenty of languages where you may want to use values that are immutable within the context of the language, so there isn't even a way to express "let's zero out this RAM". Basically, if you don't build this in as a language feature, you have a whole lot of pressures constantly pushing you in the other direction, because why wouldn't you want to avoid the cost of zeroing memory if you can? All kinds of reasons to try to avoid that.

kbolino 11mo ago

Go has both assembly language and unsafe pointer operations available. While any uses of these more advanced techniques should be vetted before going to production, they are obviously able to break out of any sandboxing that you might otherwise think a garbage collector provides. And any language which can call C code that is resident in the same virtual memory space can have its own restrictions bypassed by said C code. This even applies to more restrictive runtimes like the JVM or Python.

vlovich123 11mo ago

Go is not a memory safe language. Even in memory safe languages, memory safety vulnerabilities can exist. Such vulnerabilities can be used to hijack your process into running untrusted code. Or as others point out sibling processes could attack yours. This underlying principle is defense in depth - you make add another layer of protection that has to be bypassed to achieve an exploit. All the chains combined raise the expense of hacking a system.

tptacek 11mo ago
Respectfully, this has become a message board canard. Go is absolutely a memory safe language. The problem is that "memory safe", in its most common usage, is a term of art, meaning "resilient against memory corruption exploits stemming from bounds checking, pointer provenance, uninitialized variables, type confusion and memory lifecycle issues". To say that Go isn't memory safe under that definition is a "big if true" claim, as it implies that many other mainstream languages commonly regarded as memory safe aren't. Since "safety" is an encompassing term, it's easy to find more rigorous definitions of the term that Go would flunk; for instance, it relies on explicit synchronization for shared memory variables. People aren't wrong for calling out that other languages have stronger correctness stories, especially regarding concurrency. But they are wrong for extending those claims to "Go isn't memory safe". https://www.memorysafety.org/docs/memory-safety/ https://www.memorysafety.org/docs/memory-safety/
- vlovich123 11mo ago
  I’m not aware of any definition of memory safety that allows for segfaults- by definition those are an indication of not being memory safe. It is true that go is only memory unsafe in a specific scenario, but such things aren’t possible in true memory safe languages like c# or Java. That it only occurs in multithreaded scenarios matters little especially since concurrency is a huge selling point of the language and baked in. Java can have data races, but those data races cannot be directly exploited into memory safety issues like you can with Go. I’m tired of Go fans treating memory safety as some continuum just because there are many specific classes of how memory safety can be violated and Go protecting against most is somehow the same as protecting against all (which is what being a memory safe language means whether you like it or not). I’m not aware of any other major language claiming memory safety that is susceptible to segfaults. https://www.ralfj.de/blog/2025/07/24/memory-safety.html https://www.ralfj.de/blog/2025/07/24/memory-safety.html

hamburglar 11mo ago

The Go runtime may not be the only thing reading your process’ memory.

gethly 11mo ago

Yeah, I can hardly disagree with that sentiment myself.

tracker1 10mo ago

That's kind of the point of making it (relatively easily) accessibly... in order to ensure that secrets are wiped from memory as quickly as reasonable. This reduces a lot of potential surface area for potential attack. I used to not really see the need for this level of detail on things... then you see useful (IE in the wild exploits) for even complex factors like CPU branch prediction (for a while now), and the need starts to become much more clear.