C++ Logo

sg12

Advanced search

Re: [SG12] p1315 secure_clear

From: Nevin Liber <nevin_at_[hidden]>
Date: Fri, 24 Apr 2020 17:55:16 -0500
On Fri, Apr 24, 2020 at 5:13 PM JF Bastien via SG12 <sg12_at_[hidden]>
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?
>

Asking for clarification:

int i; // i is live and uninitialized
int i = 2;
secure_clear(&i, sizeof(i));
// is i still a live int, and if so, is it considered uninitialized?

>From both an SG12 and an LEWG point of view, it scares me to have a
mechanism to turn an initialized int into an uninitialized int.

Sidebar: It looks like C++20 already added such a mechanism :-(. I didn't
realize that the behavior for calling a pseudo-destructor had changed for
C++20 [diff.cpp17.basic] <http://eel.is/c++draft/diff.cpp17.basic#1>, as
that has implications for library and I don't remember the change going
through both SG12 and LEWG (if it did, please disregard).

In C++17 and prior, the following code had no preconditions):

std::vector<int> Copy(std::vector<int> const& v)
{ return v; }

Now it does have an undocumented precondition, which makes it a breaking
change.
-- 
 Nevin ":-)" Liber  <mailto:nevin_at_[hidden] <nevin_at_[hidden]>>
+1-847-691-1404

Received on 2020-04-24 17:58:51