4 ms·
The linked approach does not work for exactly the reasons you specify. Go can and will move and copy memory around as it sees fit, which defeats the purpose of
by stouset 10y ago
The linked approach does not work for exactly the reasons you specify. Go can and will move and copy memory around as it sees fit, which defeats the purpose of this library. You must manage the memory yourself to have any chance of doing this reliably.
https://news.ycombinator.com/item?id=14174500 https://news.ycombinator.com/item?id=14174500
- empath75 10y agoDoes hashicorp's vault have similar problems?
- cheeseprocedure 10y agoYes, but it's (reasonably) excluded from their threat model: https://github.com/hashicorp/vault/issues/1446#issuecomment-221625921 https://github.com/hashicorp/vault/issues/1446#issuecomment-...
- deleted 10y ago[deleted]
- mitchellh 10y agoNot in the same way. Vault performs an mlock on its entire memory space (all current and future pages). So even as Go copies and moves around memory, none of the process memory should ever be paged to disk. As cheeseprocedure correctly stated, we exclude memory access from our threat model. Even if you're disallowing the system from paging your memory, there are other ways of accessing a process's memory. Direct access to Vault's address space is not covered by our threat model. This doesn't mean we don't care about the problem completely: we'll make a reasonable effort in cases to protect against things even not covered by our threat model. However, due to the nature of Go or the complexity to create a locked down solution, we can't claim to cover it in our model. Vault has mlocked memory (what this library does) since its first release (0.1).
- patrickmn 10y agoWiping memory was already a part of Go crypto libs a few years ago, but was taken out because it gave a false sense of security (the secrets can be copied all over memory.)