> But I think my original point was that any proposal like Robin's
> of the form "We should standardize a library function that makes
> things secure by magic" is likely to encounter a lot of pushback....

Robin (me) wouldn't recommend standardizing any magic, my own or others,
that hasn't first been implemented so it can be tested.

Robin Rowe
Beverly Hills, California
*Chairman ISO WG21 SG14 C++ Banking and Financial Systems Subcommittee

On 3/3/2024 7:04 PM, Arthur O'Dwyer wrote:
> On Fri, Mar 1, 2024 at 6:39 PM James Mitchell <james_at_[hidden]
> <mailto:james_at_[hidden]>> wrote:
>
> I rarely jump into these discussions, but that list of cons for
> secure_memset seems like a bunch of extreme edge cases. [...]
>
> > It will get swapped to disk
>
> This seems like a strawman argument, it _could_ get swapped out to
> disk, but typically your getting the secret using it then clearing
> it, for it to be swapped out to disk the OS needs to have determined
> that between that period of time that it felt it was crucial to swap
> it to disk which is going to be rare, and only in a multi-threaded
> environment would something inside that process see it.
>
> > memset will zero out the L1 /cache/ but fail to zero out the
> L2/L3 cache or main memory
>
> This seems like another strawman argument, most read primitives are
> just that, a read primitive, I would love to see what technique
> you'll use for a common read primitive to gain access to that memory
> with a common read primitive? I assume this would be hoping to use
> different threads and race for it hoping that cache coherence
> doesn't get in the way. At the same time why don't we account for
> someone sniffing the network, reading from disk, etc.
>
> > your magic memset will zero out the buffer you pointed it at, but
> it won't zero out the other copies of that same data that the
> optimizer caused to be made (trivially, thus undetectably) all over
> the stack, under the As-If Rule
>
> This is the only semi-reasonable one in your list, however I'm not
> certain that it really stands up much either. [i.e. the optimizer
> probably doesn't make secret copies of strings, and most secrets are
> (non-SSO) strings...]
>
> The API you use might make copies (e.g. copy to a buffer to send
> over the network) but that's within the control of the person
> writing the code (and whatever libraries they use).
>
> This is where instead of guaranteeing that it will be removed which
> is impossible [...]
>
>
> Well, I mean, I'm not really trying to die on the hill of "secure_clear
> was a silly idea," /especially/ as that hill has already been taken
> (WG14 adopted the feature). But all of your rebuttals could be viewed as
> pretty weak too. Imagine going to any security firm with a list of
> potential exploits, and imagine they responded with "Well, that _could_
> happen, but typically it would be rare," and "Well, sure that could
> happen, but at that point why don't we account for someone sniffing the
> network too," and "I'm not certain that the optimizer would do that [but
> I'm not certain it wouldn't, either]," and "Yes, after we scrub the
> secrets we might call into a third-party API that leaks them right away,
> but that's /their/ coding problem not ours," and so on. The challenge
> may have been weak, but the rebuttal isn't terribly strong either!
> As long as the entire exercise remains hypothetical, I don't think we
> can say whether either side is "correct."
>
> If we discover, 10 years from now, that some libc vendor is shipping a
> `memset_explicit` implementation that is recognized as a dead write by
> GCC and optimized away, then we'll /certainly know/ that
> `memset_explicit` was worse than useless (because it lulled people into
> a false sense of security). But assuming that /never/ happens, then
> everyone will just have their respective vague feelings.
>
> I don't think we should let perfect get in the way of implementing
> an obvious solution which has been done by industry for quite a while.
>
>
> It's totally reasonable to say "industry does this, let's standardize
> it" [/cough/ trivial relocatability /cough/]. But the flip side is — as
> WG21 recently discussed in Kona re `benchmark::DoNotOptimize` — for some
> things industry has long experience, and the great benefit of a single
> implementation. Moving something like `benchmark::DoNotOptimize` or
> `SecureZeroMemory` from Google Benchmark resp. Win32 into the STL, means
> replacing one old battle-scarred implementation with three brand-new
> implementations. It's not clear that that's better.
> (But, on the pro side, here the library vendor is not so much
> /replacing/ SecureZeroMemory, explicit_bzero, etc., as providing /a thin
> façade over/ one of them. And on the con side: the vendor /can't/
> actually do that, because all the prior art is shaped like `bzero`
> whereas the thing WG14 standardized is shaped like `memset`! I actually
> don't know what vendors are going to do about that. Maybe do a secure
> clear, optionally followed by an "insecure memset" in the case that the
> `c` argument can't be statically proven to be '\0'? I think that should
> work fine.)
>
> Do you have any CVEs or realistic PoCs to show that cases where
> things like secure_memset have been used have still led to secrets
> leaking? Or is it just all hypothetical?
>
>
> As far as I know, all of the arguments pro and con have been hypothetical.
>
> This entire subthread is basically recapped at
> https://www.gnu.org/software/libc/manual/html_node/Erasing-Sensitive-Data.html <https://www.gnu.org/software/libc/manual/html_node/Erasing-Sensitive-Data.html>
> so maybe I should have just pointed there in the first place. ;D But I
> think my original point was that any proposal like Robin's of the form
> "We should standardize a library function that makes things secure by
> magic" is likely to encounter a lot of pushback (citing various physical
> reasons that feel more or less plausible to different people) and he
> should study the archives re: P1315 for a sense of how it might go.
>
> Cheers,
> Arthur
>
> _______________________________________________
> SG14 mailing list
> SG14_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg14