C++ Logo


Advanced search

Re: [SG12] p1315 secure_clear

From: JF Bastien <cxx_at_[hidden]>
Date: Fri, 24 Apr 2020 15:35:37 -0700
On Fri, Apr 24, 2020 at 3:26 PM Niall Douglas <s_sourceforge_at_[hidden]>

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

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.

Received on 2020-04-24 17:38:47