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.
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.
Sorry, but I’m super tired of “blah_blah_blah, written in Go” articles/titles (two so far today). If Go has some amazing feature, great! Let’s talk about it. If a program has some amazing feature, great! Let’s talk about that. All these “blah_blah_blah, written in Go” articles make it sound like Go is retarded in some way and that the ability to actually write programs in Go is somehow amazing. Is that really the case?
I don’t recall being inundated with “blah_blah_blah, written in C, C++, Swift, Rust, Erlang, C#, Java, Python, Ruby, Elixir, etc.” articles. Why do we have to constantly remind everyone that you can actually write programs in Go?
In this case, this is a library for Go, not a standalone program, so it seems worthwhile to include the language in the description. If there's something technical about Go that makes pure-go implementations of things interesting it's that it's uncommon/frowned upon to use cgo to import c dependencies whereas in python/ruby/etc you can trivially wrap a C library for many things and call it a day.
Also, you mention you don't see similar posts for other languages, however, similar complaints are constantly lodged against Rust posts, maybe even more so than Go. A recent comment in one of those threads also mentioned similar musings were common against python earlier in its history.
Regardless, Go and Rust are popular languages on HN right now because they're new and interesting and being used to build interesting new software. In practice, other older languages are more popular for work, but as the library ecosystems improve, maybe that will change or maybe it won't.
I remember how rabbid the python, perl and php fan boys all were back in the early days of their existence and how irritating they were to every one else.
I think its a sign of a language with a growing user base, and I suspect is that languages that don't generate this kind of fan base die off much earlier on.
They explain that I dislike Go. I thought my comments on it made that clear. I think Go is a half-baked throw-back language that handles threading, errors, and dependencies poorly, and is restrictive and lacks features. If Google hadn’t invented it, I doubt it would have any sort of following at all.
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?
> 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.
25 comments
[ 4.3 ms ] story [ 56.2 ms ] threadFor 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
[1] https://spacetime.dev/memory-retention-attacks
https://docs.microsoft.com/en-us/windows/win32/api/dpapi/nf-...
I don’t recall being inundated with “blah_blah_blah, written in C, C++, Swift, Rust, Erlang, C#, Java, Python, Ruby, Elixir, etc.” articles. Why do we have to constantly remind everyone that you can actually write programs in Go?
Those are too popular as well, e.g.:
https://news.ycombinator.com/item?id=18895655, https://news.ycombinator.com/item?id=19583384, https://news.ycombinator.com/item?id=19686972, https://news.ycombinator.com/item?id=19064069, https://news.ycombinator.com/item?id=19540845, https://news.ycombinator.com/item?id=18903235, https://news.ycombinator.com/item?id=19541741, https://news.ycombinator.com/item?id=19883626, https://news.ycombinator.com/item?id=19471471, https://news.ycombinator.com/item?id=18696291, ...
Love this!
Also, you mention you don't see similar posts for other languages, however, similar complaints are constantly lodged against Rust posts, maybe even more so than Go. A recent comment in one of those threads also mentioned similar musings were common against python earlier in its history.
Regardless, Go and Rust are popular languages on HN right now because they're new and interesting and being used to build interesting new software. In practice, other older languages are more popular for work, but as the library ecosystems improve, maybe that will change or maybe it won't.
Plus the written in C, Pascal, C++, Modula-2, Java... was taking place on BBS, USENET and written media, so hardly easy to find on HN.
I remember how rabbid the python, perl and php fan boys all were back in the early days of their existence and how irritating they were to every one else.
I think its a sign of a language with a growing user base, and I suspect is that languages that don't generate this kind of fan base die off much earlier on.
> For me, the best way to optimize a Go program is to write it in Rust.
That, along with other anti-Go comments, explains things.
Blog post about the project: https://spacetime.dev/memory-security-go
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?
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.