Go Proposal: Secret Mode

Does it? I'm not disputing you, I'm curious why you think so.

I'm not sure there's a realistic alternative. If you need to generate a key then it has to happen somehow on unsupported platforms. You can check Enabled() if you need to know and intend to do something different but I assume most of the time you run the same function either way you'd just prefer to opt into secret mode if it's available.

  // Enabled reports whether Do appears anywhere on the call stack.

Meh, this is a defence in depth measure anyway

  dangerousAllowSecretsToLeak()

  enclave, err := secret.GetEnclave()
  // err contains whether the platform doesn't support it
  enclave.Do(f)

Nah, Java and .NET are much better, but they aren't fashionable.

I'd probably want some way to understand whether secret.Do is launched within a secret-supporting environment so that I'm able to show some user warning / force a user confirmation or generate_secrets_on_unsupported_platforms flag.

But, this is probably a net improvement over the current situation, and this is still experimental, so, changes can happen before it gets to GA.

Guessing it's also taking sure to use assembly calls to zero out and clear the memory region as part of the GC... I would guess the clear/gc characteristics are otherwise the same, but having access to RAM in a non-supported platform could, in theory allow for stale reads of raw memory.

This is likely done for platform performance and having a manual version likely hinders the GC in a way that's deemed too impactful. Beyond this, if SysV or others contribute specific patches that aren't brute forced (such as RiscV extensions), I would assume that the go maintainers would accept it..

> Go has the best support for cryptography of any language

Writing cryptography code in Go is incredibly annoying and cumbersome due lack of operator overloading, forcinforcing you to do method calls like `foo.Add(bar.Mul(baz).Mod(modulus)).Mod(modulus)`. These also often end up having to be bignums instead of using generic fixed-size field arithmetic types. Rust has incredibly extensive cryptographic libraries, the low-level taking advantage of this operator overloading so the code ends up being able to following the notation in literature more closely. The elliptic_curve crate in particular is very nice to work with.

I have to wonder if we need, say, a special "secret data" type (or modifier) that has the semantics of both crypto/subtle and runtime/secret. That is to say, comparison operators are always constant-time, functions holding the data zero it out immediately, GC immediately zeroes and deallocs secret heap allocations, etc.

I mean, if you're worried about ensuring data gets zeroed out, you probably also don't want to leak it via side channels, either.

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.

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.) 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.

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

Yeah, I can hardly disagree with that sentiment myself.

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.

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.

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.

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.

without language level support, it makes code look like a mess.

Imagine, 3 level nesting calls where each calls another 3 methods, we are talking about 28 functions each with couple of variables, of course you can still clean them up, but imagine how clean code will look if you don't have to.

Just like garbage collection, you can free up memory yourself, but someone forgot something and we have either memory leak or security issues.

  secretStash := NewSecretStash()
  pString := secretStash.NewString()
  ....
  ....
  secretStash.Thrash()

    read -p “Password: “ PASSWD
    #Do something $PASSWD
    PASSWD=“XXXXXXXXXXXXXXXXXX”

    key := make([]byte, 32)
    defer scramble(&key)
    // do all the secret stuff

    func do_another_important_thing(key []byte) []byte {
       newKey := append(key, 0x0, 0x1) // this might make a copy!
       return newKey
    } 

    key := make([]byte, 32) 
    defer scramble(&key) 
    do_another_important_thing(key)
    // do all the secret stuff

It is fundamentally not possible to be in complete control of where the data you are working with is stored in go. The compiler is free to put things on the heap or on the stack however it wants. Relatedly it may make whatever copies it likes in between actions defined in the memory model which could leak arbitrary temporaries.

Hard to understand what you’re asking. This is the solution that will practical and built-in. This is a summary of a new feature coming to Go’s runtime in 1.26.

Rust doesn't have anything like this either. I think you misunderstood what it is.

    fn secret_func() -> LargeType {
        /* do some secret calculations */
        LargeType::init_with_safe_Data()
    }

  use std::ptr;
  
  struct SecretData {
      data: Vec<u8>,
  }
  
  impl Drop for SecretData {
      fn drop(&mut self) {
          // Zero out the data
          unsafe {
              ptr::write_bytes(self.data.as_mut_ptr(), 0, self.data.len());
          }
      }
  }

More likely they'll use it and end up with a false sense of security.

My guess is that it just uses the existing finalizers and ensures the memory is overwritten.

https://pkg.go.dev/runtime#SetFinalizer

My guess is that the GC will eagerly wipe+free "secret" memory first and completely on the pass as opposed to deferring to the next GC cycle as is the normal use that may otherwise happen on longer GC cycles to keep overall performance characteristics happy.

This is just my own speculation, I don't know the internals of Go beyond a few articles I've read over the years. Somewhat more familiar with C#, JS and Rust, and even then I'll sometimes confuse certain features between them.

> How does this little software enclave get key material in that doesn't transit untrusted memory?

Linux has memfd_secret ( https://man7.org/linux/man-pages/man2/memfd_secret.2.html ), that allow you to create a secure memory region that can't be directly mapped into regular RAM.

PFS is just one of many desirable properties, and getting access to plaintext is just one of many kinds of threat. Getting access to ephemeral keys and other sensitive state can enable session hijacking. It's still not a great example, though, because it doesn't illustrate that threat model either.

If it's no longer readable by software that's at least far better than no protection, I imagine

I think it may be about the absolute memory address to the secret being stored, which may itself be exploitable. That’s my hunch at least, but I’m not a security expert.

The example could probably have been better phrased.