On Fri, Apr 24, 2020 at 3:36 PM JF Bastien via SG12 <sg12_at_[hidden]>
wrote:

> On Fri, Apr 24, 2020 at 3:26 PM Niall Douglas <s_sourceforge_at_[hidden]>
> wrote:
>
>> On 24/04/2020 23:12, JF Bastien via SG12 wrote:> Hello SG12/UB folks,
>> >
>> > I'd like to start a discussion about p1315 <http://wg21.link/p1315>
>> > secure_clear. Please see the paper's history on github
>> > <https://github.com/cplusplus/papers/issues/67>.
>> >
>> > Here's what I'd want SG12's help on: assume that there's a need for
>> > some sort of "secure clearing of memory", how do we fit this into the
>> > abstract machine? What behavior do we specify, what do we leave open,
>> > while meeting the stated security goals?
>>
>>
>> All attempts to date have foundered on how best to tell the abstract
>> machine to inhibit the dead store elimination.
>>
>> Re: WG14, my ensure_stores() proposal got weak support. A secure clear
>> would be a memset() followed by an ensure_stores() to the same region.
>>
>> SG1, SG12 and other parts of WG21 truly hate the ensure_stores()
>> proposal. I'll be blunt in stating that in my opinion, nobody has
>> produced anything better. Various members of SG1 hand waved that they'd
>> have something better at some unspecified point in the future.
>>
>> I'll be still more blunt: ensure_stores() is the only one of any of the
>> hand wavy putative alternatives with a reference implementation in
>> production for several years. We know it works.
>>
>> All that said, if somebody has an elegant improvement, I'm all ears.
>>
>
> Your response is about another paper than p1315. Can you fork another
> thread? I want to get feedback on secure_clear, including to the questions
> I asked.
>

This comment was on-topic for this thread. Let me re-phrase this into
commentary on p1315:

  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.

And my own 2c: from what I've heard from security-minded folks, the
"secure_clear" approach does not and cannot work. Compilers spill values
into additional memory and registers, and any mechanism that intends to
provide an actual security guarantee needs to deal with data leaking
through those side channels. A proposal that doesn't consider those side
channels and close them gives the impression of security without providing
actual security. And those side channels cannot be closed with an interface
that looks and acts like a function call.

(FWIW, I know nothing about ensure_stores and whether it would address the
problems I mentioned above. I'm not backing any particular horse, but the
ability to implement this with actual security guarantees is a key
requirement, and one of the reasons that memset_s is not useful is that it
cannot give those guarantees due to the problem I mentioned above.)


> I agree that discussing implementation experience is important. There's
> plenty for memset_s, which secure_clear was initially trying to be. A
> discussion of that experience in the context for secure_clear would indeed
> be useful.
> _______________________________________________
> 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/0855.php
>