C++ Logo

sg12

Advanced search

Re: [SG12] p1315 secure_clear

From: Niall Douglas <s_sourceforge_at_[hidden]>
Date: Fri, 24 Apr 2020 23:57:25 +0100
On 24/04/2020 23:35, JF Bastien wrote:

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

It's the identical problem: anybody who has proposed anything which
involves overriding dead store elimination has foundered on the same
thing. And it is pertinent, you can trivially implement a secure clear
using ensure_stores(), and thus you no longer need a specific secure
clear function. There is also ample use cases for an operation
preventing dead store elimination in safety critical and anywhere else
where you need to tell the compiler "always do this, but without the
awful performance of volatile".

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

I believe WG14 have deprecated the Annex in which memset_s() is located.
I was in the room when that was discussed, and it was widely viewed as
one of the most useful functions in that Annex.

Moreover, I'm sure you JF like me and most of the committee have written
a secure clear function at least once in our career. There is clearly a
need. I wish you luck on persuading the appropriate people to let
something like it through.

Niall

Received on 2020-04-24 18:00:27