Is seems to me that imposing on compiler writers the burden of
"not leaking secrets" is something a bit excessive (of course, I'm
not a compiler writer, so I'm speaking with empathy here, and might
be contradicted by those who know better). Hostile parties are quite
imaginative in the ways they try to access information they should
not normally be privy to, and I find it difficult to guess what
they might think of. When I was writing military software, our
contracts imposed a number of security strategies I found surprising,
but they were based on prior... unpleasant... experiences.

For that reason, I hope that whatever the specifications of secure_clear
(secure_fill? secure_memset? [[secure_clear]]? something else?) end up
being, they define clearly the boundaries and expectations around this
function in objective and measurable ways. It would make it more reasonable
for an implementation to commit to meeting these expectations.

In p1315r5, we have this paragraph:

" The secure_clear function is intended to make the contents of the memory
range [data, data + size) impossible to recover. It can be considered
equivalent to a call to memset(data, value, size) with indeterminate values
(i.e. there may even be different values, e.g. randomized). However, the
compiler must guarantee the call is never optimized out unless the data was
not in memory to begin with. "

The first phrase, taken alone, seems challenging; I would find it difficult
to
guarantee that whatever strategy I picked to implement this function would
effectively meet this requirement regardless of the imaginative prowess of
hostile parties. The entire paragraph puts it more in contextand I agree
with
the intent.



Le jeu. 30 avr. 2020 à 16:11, Ville Voutilainen via SG12 <
sg12_at_[hidden]> a écrit :

> On Thu, 30 Apr 2020 at 22:35, Richard Smith via SG12
> <sg12_at_[hidden]> wrote:
> > 1) I think what you're suggesting is less different from adding a
> standard attribute than you're suggesting. Implementations cannot entirely
> ignore standard attributes; they are still required to implement the checks
> that the attributes are applied to the right kind of entity and reject if
> not, and perform whatever other checks are described in the specification
> for the attribute. An implementation that completely ignores a standard
> attribute (skips it without even parsing and validating it) does not
> conform to the standard containing that attribute, at least for all of the
> existing attributes. The situation with your keyword would be largely the
> same; the only difference is what happens in the case where an (old or
> non-conforming) implementation that has not implemented the proposal in
> question sees the attribute: does it reject due to hitting a keyword it's
> never heard of, or does it (probably silently) ignore it? Maybe that's an
> argument in favor of a non-attribute, but you can
> get the same result by checking for __has_cpp_attribute and #erroring if
> it's unavailable, which I'd expect libraries to do anyway, so I think it's
> a weak argument, and maybe too weak to justify adding a keyword.
>
> That seemed a good argument to me to make constinit a keyword. It
> can't then be semi-silently ignored,
> because ignoring it was deemed bad. I'm not qualified to make a call
> on the badness of ignoring a request
> to not leak secrets, but it seems remotely plausible that accepting
> such a request and then leaking
> secrets all over the place is irksome to say the least. I don't have
> all that clear ideas how to avoid that
> irk.
> _______________________________________________
> SG12 mailing list
> SG12_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/sg12
> Link to this post: http://lists.isocpp.org/sg12/2020/04/0895.php
>