+1.

You need a policy that applies to the entire interpretation - C++ semantics (and C semantics) aren't compositional/modular where you understand the entire possible behavior by just focusing on one function at a time.

-- Gaby
________________________________
From: SG12 <sg12-bounces_at_[hidden]> on behalf of Richard Smith via SG12 <sg12_at_[hidden]>
Sent: Friday, April 24, 2020 5:25:40 PM
To: sg12_at_[hidden] <sg12_at_[hidden]>
Cc: Richard Smith <richardsmith_at_[hidden]>; miguel_at_[hidden] <miguel_at_[hidden]>
Subject: Re: [SG12] p1315 secure_clear

On Fri, Apr 24, 2020 at 3:36 PM JF Bastien via SG12 <sg12_at_[hidden]<mailto:sg12_at_[hidden]>> wrote:
On Fri, Apr 24, 2020 at 3:26 PM Niall Douglas <s_sourceforge_at_[hidden]<mailto: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<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwg21.link%2Fp1315&data=02%7C01%7Cgdr%40microsoft.com%7Cc209a5b166564c5dc37e08d7e8af3d49%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637233711661796454&sdata=lIjO9Bco4%2BfigOlgI3ybgA6ChYf6%2B5GgUieLSYw4tL4%3D&reserved=0>>
> secure_clear. Please see the paper's history on github
> <https://github.com/cplusplus/papers/issues/67<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcplusplus%2Fpapers%2Fissues%2F67&data=02%7C01%7Cgdr%40microsoft.com%7Cc209a5b166564c5dc37e08d7e8af3d49%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637233711661806455&sdata=sLiXG8xeZl1KqJwsO%2BTNvB60qCKvx2ORJCCckivZ0Zo%3D&reserved=0>>.
>
> 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]<mailto:SG12_at_[hidden]>
Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/sg12<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fsg12&data=02%7C01%7Cgdr%40microsoft.com%7Cc209a5b166564c5dc37e08d7e8af3d49%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637233711661806455&sdata=lYb5TQvc1Kd5u34oiUixH7DXhiqVfKxhpzaY0T%2FNhlc%3D&reserved=0>
Link to this post: http://lists.isocpp.org/sg12/2020/04/0855.php<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fsg12%2F2020%2F04%2F0855.php&data=02%7C01%7Cgdr%40microsoft.com%7Cc209a5b166564c5dc37e08d7e8af3d49%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637233711661816441&sdata=rzl1OHyDtFNyLwOJnXvjjLDfiO5UEKLq%2FVxtgSb5q%2FU%3D&reserved=0>