On Fri, Apr 24, 2020 at 9:21 PM Miguel Ojeda via SG12 <sg12_at_[hidden]>
wrote:

> On Sat, Apr 25, 2020 at 2:25 AM Richard Smith <richardsmith_at_[hidden]>
> wrote:
> >
> > There has been no reference implementation of p1315 that has been used
> in production for any significant amount of time (several years). We do not
> know that its approach works.
>
> Indeed, there is no reference implementation of exactly P1315, but
> there are many implementations out there of the same
> idea/function/concept, as referenced by the proposal. They have been
> in production use for many years, in systems shipped to billions of
> users. The approach definitely works *for what the projects use them*.
> Whether that usage is good or not is another question that (see next
> point).
>
I believe Richard is very correct here. P1315 proposes a new mechanism
insofar as it suggests that a compiler may (and is encouraged to) avoid
involving actual memory for operating on the "secrets" in the first place
and thereby gain permission to omit the clearing operation. This suggests a
compiler built-in, which is almost the complete opposite of any solutions
that depend on the definition of the clearing functions being unknown to
the compiler.


> [ ... ]
> Put another way: in the worst case, projects will still use the same,
> "wrong" approach. In the best case, they at least avoid bugs related
> to their workarounds (trying to achieve the same functionality) and
> everyone gets a standard verb to refer to that operation.
>
In the worst case, the standardized functionality is implemented in a
compliant manner that offers less security than the "workarounds" used by
the projects. This may be caused by "invention" on the part of the paper or
implementers of such in the form of a new compiler built-in.