
MemGuard: Secure sensitive information in memory in Go - ngaut
https://github.com/awnumar/memguard
======
monocasa
So, we just finished extricating this from our codebase.

My main issues:

1) The underlying primitives weren't really meant for this use case. They
don't guarantee that a copy is flushed to disk, just that the canonical copy
remains in RAM.

2) By creating pointers that are ostensibly supposed to be used, that aren't
known to the GC, you're opening yourself up to a whole lot of use after free
vulnerabilities, and just generally breaking the memory safety of the runtime.
The other main area where you deal with raw non-GCed pointers like this is
CGo, where you generally marshal into the GCed world as fast as you can for
the reasons above.

3) What's the actual threat model here? Is stopping people from reading a core
dump worth breaking the memory safety of the runtime?

~~~
techslave
> 3) What's the actual threat model here? Is stopping people from reading a
> core dump worth breaking the memory safety of the runtime?

well yeah. that’s the point. if you don’t want to write an entire application
in C to prevent this. if for your application it’s not worth it, you live with
it.

~~~
monocasa
I can't quite follow all of the indefinite pronouns. Can you restate?

------
mehrdadn
Probably not a big deal, but they're reinventing the wheel a bit... Windows
has RtlEncryptMemory/CryptProtectMemory for this.

[https://docs.microsoft.com/en-
us/windows/win32/api/dpapi/nf-...](https://docs.microsoft.com/en-
us/windows/win32/api/dpapi/nf-dpapi-cryptprotectmemory)

~~~
christoph-heiss
Not really a cross-platform API, is it?

~~~
mehrdadn
No, but I'm suggesting it's not a bad idea to use it on Windows. That way if
there's ever an improvement made to it (imagine better hardware support or
something coming along someday), you'd get it automatically.

------
nsajko
Previous discussion:
[https://news.ycombinator.com/item?id=14173716](https://news.ycombinator.com/item?id=14173716)

Blog post about the project: [https://spacetime.dev/memory-security-
go](https://spacetime.dev/memory-security-go)

~~~
libeclipse
More recent post about the project: [https://spacetime.dev/encrypting-secrets-
in-memory](https://spacetime.dev/encrypting-secrets-in-memory)

------
java-man
I think we need something like this in java runtime.

------
bbmario
Does anyone know anything similar for C/C++?

~~~
johnisgood
[https://github.com/jedisct1/libsodium-
doc/blob/master/helper...](https://github.com/jedisct1/libsodium-
doc/blob/master/helpers/memory_management.md)

~~~
bbmario
Had no idea libsodium provided that. Thank you!

------
azhenley
How much does it impact performance?

~~~
libeclipse
There is a memory overhead associated with guarded heap allocations. The time
overhead is only applicable when creating or destroying them.

For encrypted data there is virtually no memory overhead but a guarded
allocated has to be created to hold the decrypted data when it is needed.

The root encryption key is stored within a special container [0, 1] that has
some small but constant CPU overhead as it is continuously mutating the memory
associated with the structure in the background. This overhead can be tweaked
(or even virtually eliminated) by changing the interval between successive
cycles.

[0] [https://spacetime.dev/encrypting-secrets-in-
memory](https://spacetime.dev/encrypting-secrets-in-memory)

[1] [https://spacetime.dev/memory-retention-
attacks](https://spacetime.dev/memory-retention-attacks)

