P1315 secure_clear / memset_explicit

[jensmaurer]

P1315R1 secure_val: a secure-clear-on-move type (Miguel Ojeda)

Other papers related to abstract machine semantics:

• N4534 Data-Invariant Functions (revision 3)
• P0928 Mitigating Spectre v1 Attacks in C++ P0928 Mitigating Spectre v1 Attacks in C++ #725
• P1382 volatile_load<T> and volatile_store<T> P1382 volatile_load<T> and volatile_store<T> #167

[jensmaurer]

Ville in http://lists.isocpp.org/lib-ext/2019/02/10157.php: Optimization barriers of any sort are EWG territory.

[jfbastien]

Ryan McDougall volunteered to present in Kona, the author will be present at one of the upcoming European meetings.

[jensmaurer]

Discussion on lib-ext: http://lists.isocpp.org/lib-ext/2019/01/10033.php

[brycelelbach]

@jfbastien Please send this back to LEWGI when you are done with it.

[jfbastien]

Remove all cache related things from the proposal.
SF F N A SA
3 1 3 0 0
Remove encrypting at rest from the proposal.
SF F N A SA
4 1 1 1 0
(A vote: encryption is a novel thing about the proposal)
Want secure_clear to write indeterminate values (as opposed to memset_s).
SF F N A SA
4 1 2 0 0
Want to work with WG14 on secure_clear (e.g. salvage memset_s from Annex K).
SF F N A SA
2 3 2 0 0
We want something along the lines of secure_val (with compiler support).
SF F N A SA
0 0 2 2 3

[wg21bot]

P1315R2 secure_clear (Miguel Ojeda)

[jfbastien]

EWGI in Cologne:

Spend committee time on this versus other proposals, given that time is limited?
SF F N A SA
2 9 2 1 0
Send the paper to SG1 for input on abstract machine integration and wording (similar to volatile_load / volatile_store). Send it back to us after.
SF F N A SA
4 5 4 0 0

[wg21bot]

P1315R3 secure_clear (Miguel Ojeda)

[AaronBallman]

Adding needs-revision because the author is working on an update to the paper currently.

[brycelelbach]

2021-05-25 Library Evolution Telecon

P1315R7: memset_explicit

2021-05-25 Library Evolution Telecon Minutes

Chair: Nevin Liber

Champion: Miguel Ojeda

Minute Taker: Ben Craig

Summary

A fair bit of discussion on what the intended and guaranteed semantics of this function are (the paper says it is implementation-defined) and whether it should apply to trivially copyable types, trivially destructible types and/or implicit lifetime types.  Discussion then moved on to how does calling memset_explicit on an object interact with the lifetime of that object.  Ultimately, those are all things that are better discussed in other groups with their expertise.

We briefly discussed adding a range-type interface, but ended up deciding to remove the C++-specific interface from the proposal.

Outcome

Voted to remove the C++ templated interface from the proposal, leaving the C interface (and LEWG does not need to see that revision). The revision of this paper should be run by the SSRG and back to EWG to decide what to do with it.

[ojeda]

the paper says it is implementation-defined

Note: only in some of the alternatives -- it is not clear what WG14 will decide (last time this was polled, people were evenly split between A1 and A2), and we have a pending, new wording suggested too from the reflector.

[jensmaurer]

@ojeda, there is a "needs-revision" label on this entry. Do you agree this paper should be updated before being scheduled in other groups?

[ojeda]

The paper will be updated at least once for WG14, yeah.

[jensmaurer]

WG14 has looked at the paper, but has not come to a conclusion. It seems fair to say this won't make it into C++23. Removing "C++23" label.

[ThePhD]

WG14 has looked at the C version of this paper and it is accepted for C23 as memset_explicit. WG21 will receive memset_explicit as part of their implicit C library importation (when they rebase on C23); nothing about memset_explicit is surprising or different from what WG21 would expect its signature to look like.

WG21 can figure out secure_clear without SG22 decision making, as that interface need not be directly compatible as a std:: entity with the existing C memset_explicit.

[jfbastien]

Given that C adopted the paper, LEWG should decide how to proceed, and then refer the paper to the right groups if needed. @inbal2l

[cor3ntin]

This is now part of #2020 (We can reopen this issue if a new revision of the paper appear)