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).

> And my own 2c: from what I've heard from security-minded folks, the "secure_clear" approach does not and cannot work.

That should be discussed/solved by them, not us. The projects out
there, however, want to have a "secure_clear"-like function, as shown
by the proposal.

> any mechanism that intends to provide an actual security guarantee needs to deal with data leaking through those side channels.

Yes, addressing that would be ideal, as acknowledged in the proposal
itself. However, no one out there is solving all that (in major
projects I am aware of -- of course -- and a software-only solution is
most likely impossible in current popular uarchs anyway). So we are
here at an impasse, stopping "good enough" because we want "perfect".

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.

To be clear: I think we can agree that everyone acknowledges
(including the proposal and likely everyone using the implementations
out there) that this is not ideal nor that it solves everything and
that better solutions should be researched and implemented (including
hardware-based ones). Nevertheless, solving that is not the goal here.

Cheers,
Miguel