Topic: Securely wiped containers?


Author: Rob Meijer <pibara@gmail.com>
Date: Tue, 22 Jul 2014 09:35:38 +0200
Raw View
--e89a8fb1fca41f7d3704fec34504
Content-Type: text/plain; charset=UTF-8

Trying to write a library that handles a lot of sensitive security tokens
in std::string's, I queried some C++ fora about the possibilities of
assuring these tokens not lingering about in memory.  Next to the usual
half informed responses, the apparently most cluefull responses pointed out
that anything I and others suggested I could do was either STL
implementation specific or was something that the compiler would (and was
in its right to) optimize away.

Given that this is apparently a rather hard problem, and given that I'm not
that deeply into the subject that I could propose a solidified solution for
this issue,  rather than proposing one or multiple likely stupid proposals,
I would just like to drop the problem for others with a solid understanding
of the internals of the standard libraries and the optimization freedoms of
compilers to think about.

Could we think of any library proposal that would allow standard containers
to optionally get securely wiped, without the compiler legally optimizing
away the actual wiping  ?

Rob

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--e89a8fb1fca41f7d3704fec34504
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:garamond=
,serif">Trying to write a library that handles a lot of sensitive security =
tokens in std::string&#39;s, I queried some C++ fora about the possibilitie=
s of assuring these tokens not lingering about in memory. =C2=A0Next to the=
 usual half informed responses, the apparently most cluefull responses poin=
ted out that anything I and others suggested I could do was either STL impl=
ementation specific or was something that the compiler would (and was in it=
s right to) optimize away.</div>
<div class=3D"gmail_default" style=3D"font-family:garamond,serif"><br></div=
><div class=3D"gmail_default" style=3D"font-family:garamond,serif">Given th=
at this is apparently a rather hard problem, and given that I&#39;m not tha=
t deeply into the subject that I could propose a solidified solution for th=
is issue, =C2=A0rather than proposing one or multiple likely stupid proposa=
ls, I would just like to drop the problem for others with a solid understan=
ding of the internals of the standard libraries and the optimization freedo=
ms of compilers to think about. =C2=A0</div>
<div class=3D"gmail_default" style=3D"font-family:garamond,serif"><br></div=
><div class=3D"gmail_default" style=3D"font-family:garamond,serif">Could we=
 think of any library proposal that would allow standard containers to opti=
onally get securely wiped, without the compiler legally optimizing away the=
 actual wiping =C2=A0?</div>
<div class=3D"gmail_default" style=3D"font-family:garamond,serif"><br></div=
><div class=3D"gmail_default" style=3D"font-family:garamond,serif">Rob</div=
></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--e89a8fb1fca41f7d3704fec34504--

.


Author: "'Dean Michael Berris' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Tue, 22 Jul 2014 17:38:45 +1000
Raw View
Can you not do this with a custom allocator for your types?

On Tue, Jul 22, 2014 at 5:35 PM, Rob Meijer <pibara@gmail.com> wrote:
> Trying to write a library that handles a lot of sensitive security tokens in
> std::string's, I queried some C++ fora about the possibilities of assuring
> these tokens not lingering about in memory.  Next to the usual half informed
> responses, the apparently most cluefull responses pointed out that anything
> I and others suggested I could do was either STL implementation specific or
> was something that the compiler would (and was in its right to) optimize
> away.
>
> Given that this is apparently a rather hard problem, and given that I'm not
> that deeply into the subject that I could propose a solidified solution for
> this issue,  rather than proposing one or multiple likely stupid proposals,
> I would just like to drop the problem for others with a solid understanding
> of the internals of the standard libraries and the optimization freedoms of
> compilers to think about.
>
> Could we think of any library proposal that would allow standard containers
> to optionally get securely wiped, without the compiler legally optimizing
> away the actual wiping  ?
>
> Rob
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.


Author: David Krauss <potswa@gmail.com>
Date: Tue, 22 Jul 2014 15:48:35 +0800
Raw View
--Apple-Mail=_A75796E2-E2F4-4DA8-B79E-78FF609C3DB7
Content-Type: text/plain; charset=ISO-8859-1


On 2014-07-22, at 3:43 PM, David Krauss <potswa@gmail.com> wrote:

> I've never thought about the compiler being allowed to eliminate a change to an object merely because the change cannot be observed before its life ends. It doesn't sound likely in practice.

To be sure, it's commonplace for stack objects, I've just not heard of such analysis for objects of dynamic lifetime. It would require the deallocation function (operator delete or free) to have a compiler hook for that specific purpose.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--Apple-Mail=_A75796E2-E2F4-4DA8-B79E-78FF609C3DB7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;07&ndash;22, at 3:43 PM, David Krauss &lt;<a href=3D"mailto:potswa@gm=
ail.com">potswa@gmail.com</a>&gt; wrote:</div><br class=3D"Apple-interchang=
e-newline"><blockquote type=3D"cite"><span style=3D"font-family: Helvetica;=
 font-size: 12px; font-style: normal; font-variant: normal; font-weight: no=
rmal; letter-spacing: normal; line-height: normal; orphans: auto; text-alig=
n: start; text-indent: 0px; text-transform: none; white-space: normal; wido=
ws: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; d=
isplay: inline !important;">I&rsquo;ve never thought about the compiler bei=
ng allowed to eliminate a change to an object merely because the change can=
not be observed before its life ends. It doesn&rsquo;t sound likely in prac=
tice.</span></blockquote></div><br><div>To be sure, it&rsquo;s commonplace =
for stack objects, I&rsquo;ve just not heard of such analysis for objects o=
f dynamic lifetime. It would require the deallocation function (operator de=
lete or free) to have a compiler hook for that specific purpose.</div><div>=
<br></div></body></html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_A75796E2-E2F4-4DA8-B79E-78FF609C3DB7--

.


Author: David Krauss <potswa@gmail.com>
Date: Tue, 22 Jul 2014 15:43:28 +0800
Raw View
--Apple-Mail=_08238289-AE2D-4770-B8A1-99C854A289ED
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2014-07-22, at 3:35 PM, Rob Meijer <pibara@gmail.com> wrote:

> Trying to write a library that handles a lot of sensitive security tokens=
 in std::string's, I queried some C++ fora about the possibilities of assur=
ing these tokens not lingering about in memory.  Next to the usual half inf=
ormed responses, the apparently most cluefull responses pointed out that an=
ything I and others suggested I could do was either STL implementation spec=
ific or was something that the compiler would (and was in its right to) opt=
imize away.

Not sure what you mean by either STL implementation specific or optimizatio=
n.

You can provide a custom allocator to std::basic_string which wipes memory =
in its deallocate() method. This receives a size_type argument. However, it=
 causes the string to have a different type than std::string, which can cau=
se great pain.

As of C++14, you can wipe memory by replacing your library's ::operator del=
ete and requesting a std::size_t second argument. This will take care of ev=
ery deallocation in the program, not only from std::string.

I've never thought about the compiler being allowed to eliminate a change t=
o an object merely because the change cannot be observed before its life en=
ds. It doesn't sound likely in practice. But, you can take care of the poss=
ibility by either marking the bytes as volatile while wiping them, or passi=
ng a reference into the allocation block to an extern function after wiping=
 it.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--Apple-Mail=_08238289-AE2D-4770-B8A1-99C854A289ED
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;07&ndash;22, at 3:35 PM, Rob Meijer &lt;<a href=3D"mailto:pibara@gmai=
l.com">pibara@gmail.com</a>&gt; wrote:</div><br class=3D"Apple-interchange-=
newline"><blockquote type=3D"cite"><div dir=3D"ltr"><div class=3D"gmail_def=
ault" style=3D"font-family:garamond,serif">Trying to write a library that h=
andles a lot of sensitive security tokens in std::string's, I queried some =
C++ fora about the possibilities of assuring these tokens not lingering abo=
ut in memory. &nbsp;Next to the usual half informed responses, the apparent=
ly most cluefull responses pointed out that anything I and others suggested=
 I could do was either STL implementation specific or was something that th=
e compiler would (and was in its right to) optimize away.</div></div></bloc=
kquote><div><br></div><div>Not sure what you mean by either STL implementat=
ion specific or optimization.</div><div><br></div><div>You can provide a cu=
stom allocator to std::basic_string which wipes memory in its deallocate() =
method. This receives a size_type argument. However, it causes the string t=
o have a different type than std::string, which can cause great pain.</div>=
<div><br></div><div>As of C++14, you can wipe memory by replacing your libr=
ary&rsquo;s ::operator delete and requesting a <font face=3D"Courier">std::=
size_t</font> second argument. This will take care of every deallocation in=
 the program, not only from std::string.</div><div><br></div><div>I&rsquo;v=
e never thought about the compiler being allowed to eliminate a change to a=
n object merely because the change cannot be observed before its life ends.=
 It doesn&rsquo;t sound likely in practice. But, you can take care of the p=
ossibility by either marking the bytes as volatile while wiping them, or pa=
ssing a reference into the allocation block to an extern function after wip=
ing it.</div><div><br></div></div></body></html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_08238289-AE2D-4770-B8A1-99C854A289ED--

.


Author: Rob Meijer <pibara@gmail.com>
Date: Tue, 22 Jul 2014 11:43:05 +0200
Raw View
--089e013cb9aee59a7104fec50c4b
Content-Type: text/plain; charset=UTF-8

There are two problems with that:

* The allocator supplied to basic_string is aparently not guaranteed to be
used for smaller string sizes.
    If its not used, than no dealocate is called and no sensitive data gets
wiped.
* Code mutating memory locations that after mutations will not longer be
used could simply be
    legally optimized away by the compiler.  Not sure if/how 'volatile'
could fix this ?




2014-07-22 9:38 GMT+02:00 'Dean Michael Berris' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org>:

> Can you not do this with a custom allocator for your types?
>
> On Tue, Jul 22, 2014 at 5:35 PM, Rob Meijer <pibara@gmail.com> wrote:
> > Trying to write a library that handles a lot of sensitive security
> tokens in
> > std::string's, I queried some C++ fora about the possibilities of
> assuring
> > these tokens not lingering about in memory.  Next to the usual half
> informed
> > responses, the apparently most cluefull responses pointed out that
> anything
> > I and others suggested I could do was either STL implementation specific
> or
> > was something that the compiler would (and was in its right to) optimize
> > away.
> >
> > Given that this is apparently a rather hard problem, and given that I'm
> not
> > that deeply into the subject that I could propose a solidified solution
> for
> > this issue,  rather than proposing one or multiple likely stupid
> proposals,
> > I would just like to drop the problem for others with a solid
> understanding
> > of the internals of the standard libraries and the optimization freedoms
> of
> > compilers to think about.
> >
> > Could we think of any library proposal that would allow standard
> containers
> > to optionally get securely wiped, without the compiler legally optimizing
> > away the actual wiping  ?
> >
> > Rob
> >
> > --
> >
> > ---
> > You received this message because you are subscribed to the Google Groups
> > "ISO C++ Standard - Future Proposals" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to std-proposals+unsubscribe@isocpp.org.
> > To post to this group, send email to std-proposals@isocpp.org.
> > Visit this group at
> > http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--089e013cb9aee59a7104fec50c4b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:garamond=
,serif">There are two problems with that:</div><div class=3D"gmail_default"=
 style=3D"font-family:garamond,serif"><br></div><div class=3D"gmail_default=
" style=3D"font-family:garamond,serif">
* The allocator supplied to basic_string is aparently not guaranteed to be =
used for smaller string sizes.=C2=A0</div><div class=3D"gmail_default" styl=
e=3D"font-family:garamond,serif">=C2=A0 =C2=A0 If its not used, than no dea=
locate is called and no sensitive data gets wiped.</div>
<div class=3D"gmail_default" style=3D"font-family:garamond,serif">* Code mu=
tating memory locations that after mutations will not longer be used could =
simply be=C2=A0</div><div class=3D"gmail_default" style=3D"font-family:gara=
mond,serif">
=C2=A0 =C2=A0 legally optimized away by the compiler. =C2=A0Not sure if/how=
 &#39;volatile&#39; could fix this ?</div><div class=3D"gmail_default" styl=
e=3D"font-family:garamond,serif"><br></div><div class=3D"gmail_default" sty=
le=3D"font-family:garamond,serif">
<br></div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quot=
e">2014-07-22 9:38 GMT+02:00 &#39;Dean Michael Berris&#39; via ISO C++ Stan=
dard - Future Proposals <span dir=3D"ltr">&lt;<a href=3D"mailto:std-proposa=
ls@isocpp.org" target=3D"_blank">std-proposals@isocpp.org</a>&gt;</span>:<b=
r>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Can you not do this with a custom allocator =
for your types?<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
On Tue, Jul 22, 2014 at 5:35 PM, Rob Meijer &lt;<a href=3D"mailto:pibara@gm=
ail.com">pibara@gmail.com</a>&gt; wrote:<br>
&gt; Trying to write a library that handles a lot of sensitive security tok=
ens in<br>
&gt; std::string&#39;s, I queried some C++ fora about the possibilities of =
assuring<br>
&gt; these tokens not lingering about in memory. =C2=A0Next to the usual ha=
lf informed<br>
&gt; responses, the apparently most cluefull responses pointed out that any=
thing<br>
&gt; I and others suggested I could do was either STL implementation specif=
ic or<br>
&gt; was something that the compiler would (and was in its right to) optimi=
ze<br>
&gt; away.<br>
&gt;<br>
&gt; Given that this is apparently a rather hard problem, and given that I&=
#39;m not<br>
&gt; that deeply into the subject that I could propose a solidified solutio=
n for<br>
&gt; this issue, =C2=A0rather than proposing one or multiple likely stupid =
proposals,<br>
&gt; I would just like to drop the problem for others with a solid understa=
nding<br>
&gt; of the internals of the standard libraries and the optimization freedo=
ms of<br>
&gt; compilers to think about.<br>
&gt;<br>
&gt; Could we think of any library proposal that would allow standard conta=
iners<br>
&gt; to optionally get securely wiped, without the compiler legally optimiz=
ing<br>
&gt; away the actual wiping =C2=A0?<br>
&gt;<br>
&gt; Rob<br>
&gt;<br>
</div></div><span class=3D"HOEnZb"><font color=3D"#888888">&gt; --<br>
&gt;<br>
&gt; ---<br>
&gt; You received this message because you are subscribed to the Google Gro=
ups<br>
&gt; &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt; To unsubscribe from this group and stop receiving emails from it, send=
 an<br>
&gt; email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std=
-proposals+unsubscribe@isocpp.org</a>.<br>
&gt; To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org">std-proposals@isocpp.org</a>.<br>
&gt; Visit this group at<br>
&gt; <a href=3D"http://groups.google.com/a/isocpp.org/group/std-proposals/"=
 target=3D"_blank">http://groups.google.com/a/isocpp.org/group/std-proposal=
s/</a>.<br>
<br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e013cb9aee59a7104fec50c4b--

.


Author: Thiago Macieira <thiago@macieira.org>
Date: Tue, 22 Jul 2014 11:57:45 -0700
Raw View
On Tuesday 22 July 2014 09:35:38 Rob Meijer wrote:
> Trying to write a library that handles a lot of sensitive security tokens
> in std::string's, I queried some C++ fora about the possibilities of
> assuring these tokens not lingering about in memory.  Next to the usual
> half informed responses, the apparently most cluefull responses pointed out
> that anything I and others suggested I could do was either STL
> implementation specific or was something that the compiler would (and was
> in its right to) optimize away.
>
> Given that this is apparently a rather hard problem, and given that I'm not
> that deeply into the subject that I could propose a solidified solution for
> this issue,  rather than proposing one or multiple likely stupid proposals,
> I would just like to drop the problem for others with a solid understanding
> of the internals of the standard libraries and the optimization freedoms of
> compilers to think about.
>
> Could we think of any library proposal that would allow standard containers
> to optionally get securely wiped, without the compiler legally optimizing
> away the actual wiping  ?

Hi Rob

The original question was: how do I ensure the bytes in a std::basic_string
get wiped?

The problems with giving a full answer to that are:

1) libstdc++ used a refcounted basic_string because C++98 didn't outright ban
it, so you can't be sure that the last reference was dropped

2) the standard does permit the "small string optimisation" (SSO) solution,
which allows basic_string to skip the allocator

3) memset can be optimised out of existence -- see Greg K-H's post
https://plus.google.com/111049168280159033135/posts/dr2pf4ku3Cd and follow-up
on how BSD solves it:
https://plus.google.com/111049168280159033135/posts/YTDoSRTrktc

Let's ignore case #1 for the moment, since C++11 ruled that refcounting was
not permitted.

If you want to scrub, there are three options:
 - before basic_string's destructor
 - during its destructor
 - after its destructor

Obviously, the standard cannot recommend doing it before the destructor.
Unlike QByteArray, basic_string does not return a non-const pointer to its
data.

Doing it during the destructor is the expected case of using the allocator,
but it won't work if SSO is in operation. And even if that were the case, the
compiler can prove the memory isn't getting used again, so problem #3 applies.

So the only case available is to do it *after* the destructor has run. That
requires you legitimately have access to the memory area where the
basic_string was placed. The only way I see that happening is if you have an
indirection to the basic_string in the first place.

Such as:
struct Wrapper
{
    std::basic_string<char, std::char_traits<char>, MyAllocator> data;
    void *operator new(std::size_t);
    operator delete(void *);
};

And always allocating that in the heap, so the operator delete member gets to
run.

At that point, it's easier to ditch std::basic_string and just new char[N]
yourself, thus avoiding a double indirection to the data in the non-small
case.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.


Author: =?UTF-8?Q?David_Rodr=C3=ADguez_Ibeas?= <dibeas@ieee.org>
Date: Tue, 22 Jul 2014 17:25:42 -0400
Raw View
--047d7bf15e44ae2ed704fecedded
Content-Type: text/plain; charset=UTF-8

On Tue, Jul 22, 2014 at 2:57 PM, Thiago Macieira <thiago@macieira.org>
wrote:

> On Tuesday 22 July 2014 09:35:38 Rob Meijer wrote:If you want to scrub,
> there are three options:
>  - before basic_string's destructor
>  - during its destructor
>  - after its destructor
>
> Obviously, the standard cannot recommend doing it before the destructor.
> Unlike QByteArray, basic_string does not return a non-const pointer to its
> data.
>

But you *do* have access to it:
{
   std::string str = f();
   memset(&str[0], 0, str.size());
}

Now you have to make sure that the optimizer does not remove that memset,
but since security trumps performance, you could hide that in a extern
function:

void reset(std::string & str) {
    memset(&str[0], 0, str.size());
}

{
    std::string str = f();
    reset(str);
}

And now you are left with only link time optimization...

David

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--047d7bf15e44ae2ed704fecedded
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Tue, Jul 22, 2014 at 2:57 PM, Thiago Macieira <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.org</a=
>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"">On Tuesday 22 July 2014 09:3=
5:38 Rob Meijer wrote:If you want to scrub, there are three options:<br></d=
iv>

=C2=A0- before basic_string&#39;s destructor<br>
=C2=A0- during its destructor<br>
=C2=A0- after its destructor<br>
<br>
Obviously, the standard cannot recommend doing it before the destructor.<br=
>
Unlike QByteArray, basic_string does not return a non-const pointer to its<=
br>
data.<br></blockquote><div><br>But you *do* have access to it:<br>{ <br>=C2=
=A0 =C2=A0std::string str =3D f();<br>=C2=A0 =C2=A0memset(&amp;str[0], 0, s=
tr.size());<br>}<br>=C2=A0<br>Now you have to make sure that the optimizer =
does not remove that memset, but since security trumps performance, you cou=
ld hide that in a extern function:<br>
<br>void reset(std::string &amp; str) {<br>=C2=A0 =C2=A0 memset(&amp;str[0]=
, 0, str.size());<br>}<br><br>{<br>=C2=A0 =C2=A0 std::string str =3D f();<b=
r>=C2=A0 =C2=A0 reset(str);<br>}<br><br>And now you are left with only link=
 time optimization...<br><br>
David</div></div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7bf15e44ae2ed704fecedded--

.


Author: Thiago Macieira <thiago@macieira.org>
Date: Tue, 22 Jul 2014 21:08:32 -0700
Raw View
On Tuesday 22 July 2014 17:25:42 David Rodr=EDguez Ibeas wrote:
> But you *do* have access to it:
> {
>    std::string str =3D f();
>    memset(&str[0], 0, str.size());
> }

Interesting, I had never noticed that operator[] is non-const.

Does the standard require that basic_string keep data contiguously? It coul=
d=20
collapse into one string only when you call c_str().

If it requires contiguous data, why is operator[] returning non-const but=
=20
data() is only const?
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.


Author: =?ISO-8859-1?Q?Daniel_Kr=FCgler?= <daniel.kruegler@gmail.com>
Date: Wed, 23 Jul 2014 08:07:02 +0200
Raw View
2014-07-23 6:08 GMT+02:00 Thiago Macieira <thiago@macieira.org>:
> Does the standard require that basic_string keep data contiguously? It could
> collapse into one string only when you call c_str().

It is guaranteed, see [string.require] p4:

The char-like objects in a basic_string object shall be stored
contiguously. That is, for any basic_string
object s, the identity &*(s.begin() + n) == &*s.begin() + n shall hold
for all values of n such that 0
<= n < s.size().

> If it requires contiguous data, why is operator[] returning non-const but
> data() is only const?

Presumably it could be changed, see

http://cplusplus.github.io/LWG/lwg-active.html#2391

There exists the requirement that the character at position == size()
is equal to charT(), so you can not *arbitrarily* scribble into it,
therefore the current hesitation (I guess).

- Daniel

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.


Author: David Krauss <potswa@gmail.com>
Date: Wed, 23 Jul 2014 14:49:55 +0800
Raw View
--Apple-Mail=_87A7C5E2-FBE7-44D9-AA59-4DF3EDAEA52B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


On 2014=E2=80=9307=E2=80=9323, at 2:07 PM, Daniel Kr=C3=BCgler <daniel.krue=
gler@gmail.com> wrote:

> There exists the requirement that the character at position =3D=3D size()
> is equal to charT(), so you can not *arbitrarily* scribble into it,
> therefore the current hesitation (I guess).

There has been some churn, but if I recall correctly, operator[] ( n ) with=
 n =E2=89=A5 size() must return a null (default-constructed) character valu=
e but this does not imply that there is a character stored at position =3D =
size(). The implementation is free to leave the null terminator uninitializ=
ed until c_str() is called, but this doesn=E2=80=99t apply to data(). (Scri=
bbling on it would be UB because it=E2=80=99s not part of the sequence, tho=
ugh!)

I cannot recall how the semantics of s.data() are supposed to differ from &=
s[0], if at all. The latter, if performed on a non-const name s, invalidate=
s a null terminator from a prior c_str() regardless of whether anything is =
subsequently overwritten.

The fundamental question, IIRC, is whether the user can do c_str() and then=
 data() and then still use the C string. Currently it is allowed, but non-c=
onst data() could in theory break something. The difference is so pedantic =
that it=E2=80=99s starting to give me a headache already.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--Apple-Mail=_87A7C5E2-FBE7-44D9-AA59-4DF3EDAEA52B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;"><br><div><div>On 2014=E2=80=
=9307=E2=80=9323, at 2:07 PM, Daniel Kr=C3=BCgler &lt;<a href=3D"mailto:dan=
iel.kruegler@gmail.com">daniel.kruegler@gmail.com</a>&gt; wrote:</div><br c=
lass=3D"Apple-interchange-newline"><blockquote type=3D"cite">There exists t=
he requirement that the character at position =3D=3D size()<br>is equal to =
charT(), so you can not *arbitrarily* scribble into it,<br>therefore the cu=
rrent hesitation (I guess).<br></blockquote></div><br><div>There has been s=
ome churn, but if I recall correctly, <font face=3D"Courier">operator[] ( n=
 )</font> with n =E2=89=A5&nbsp;<font face=3D"Courier">size()</font> must r=
eturn a null (default-constructed) character value but this does not imply =
that there is a character stored at position =3D <font face=3D"Courier">siz=
e()</font>. The implementation is free to leave the null terminator uniniti=
alized until <font face=3D"Courier">c_str()</font> is called, but this does=
n=E2=80=99t apply to <font face=3D"Courier">data()</font>. (Scribbling on i=
t would be UB because it=E2=80=99s not part of the sequence, though!)</div>=
<div><br></div><div>I cannot recall how the semantics of <font face=3D"Cour=
ier">s.data()</font> are supposed to differ from <font face=3D"Courier">&am=
p;s[0]</font>, if at all. The latter, if performed on a non-const name s, i=
nvalidates a null terminator from a prior <font face=3D"Courier">c_str()</f=
ont> regardless of whether anything is subsequently overwritten.</div><div>=
<br></div><div>The fundamental question, IIRC, is whether the user can do <=
font face=3D"Courier">c_str()</font> and then <font face=3D"Courier">data()=
</font> and then still use the C string. Currently it is allowed, but non-c=
onst <font face=3D"Courier">data()</font> could in theory break something. =
The difference is so pedantic that it=E2=80=99s starting to give me a heada=
che already.</div><div><br></div></body></html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_87A7C5E2-FBE7-44D9-AA59-4DF3EDAEA52B--

.


Author: Sebastian Gesemann <s.gesemann@gmail.com>
Date: Wed, 23 Jul 2014 10:28:03 +0200
Raw View
On Tue, Jul 22, 2014 at 9:35 AM, Rob Meijer <pibara@gmail.com> wrote:
> Trying to write a library that handles a lot of sensitive security tokens in
> std::string's, I queried some C++ fora about the possibilities of assuring
> these tokens not lingering about in memory.  Next to the usual half informed
> responses, the apparently most cluefull responses pointed out that anything
> I and others suggested I could do was either STL implementation specific or
> was something that the compiler would (and was in its right to) optimize
> away.

Maybe Botan's secure_vector is an option:
http://botan.randombit.net/manual/secmem.html

I'm not sure if it even prevents the memory from being swapped to disk
(which you might want to add if it's not already there. I'm sure
modern operating systems support it). At least, it does zeroing before
deallocation.

For the reasons mentioned (small string optimization, copy-on-write),
I would use a vector-like type for the secrets instead of std::string.

> Could we think of any library proposal that would allow standard containers
> to optionally get securely wiped, without the compiler legally optimizing
> away the actual wiping  ?

It's not my call but I would guess that standardizing something like
this is not justified.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.


Author: =?UTF-8?B?SW9uIEdhenRhw7FhZ2E=?= <igaztanaga@gmail.com>
Date: Wed, 23 Jul 2014 21:38:52 +0200
Raw View
El 22/07/2014 23:25, David Rodr=C3=ADguez Ibeas wrote:
> But you *do* have access to it:
> {
>     std::string str =3D f();
>     memset(&str[0], 0, str.size());
> }
>
> Now you have to make sure that the optimizer does not remove that
> memset, but since security trumps performance, you could hide that in a
> extern function:
>
> void reset(std::string & str) {
>      memset(&str[0], 0, str.size());
> }
>
> {
>      std::string str =3D f();
>      reset(str);
> }
>
> And now you are left with only link time optimization...
>
> David

Or use memset_s:

https://www.securecoding.cert.org/confluence/display/seccode/MSC06-C.+Bewar=
e+of+compiler+optimizations

Best,

Ion

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.


Author: Sean Middleditch <sean.middleditch@gmail.com>
Date: Wed, 23 Jul 2014 20:48:09 -0700 (PDT)
Raw View
------=_Part_394_1127132709.1406173689644
Content-Type: text/plain; charset=UTF-8

None of the answers so far are taking into account the security problems on
common general-purpose OSes with memory safety. "Wiping" memory before
deallocation is simply not enough.

General purpose OSes can use a virtual memory system to move physical pages
around in memory, to disk, etc. Just because you clear some data doesn't
mean that the OS didn't already make copies of the data elsewhere in RAM or
on disk. Many OSes provide some calls to "lock" virtual pages disallowing
any such copies or ensuring that the original copied-from pages are cleared
by the OS after copy. Using these usually incurs some kind of performance
overhead (across all processes) or requires special process privileges.

An STL allocator wouldn't just want to clear memory but also ensure that
all "secure" allocations come out of a pool of pages that are properly
protected. It would essentially be a separate heap/free-store just for
secure block allocations.

Given that not all platforms have these features available, or are
available with different conditions or limitations, or that they work in
different ways, standardizing them may be a little difficult. Possibly
worth it, but a bit more than just a new allocator or container.

On Tuesday, July 22, 2014 12:35:40 AM UTC-7, pibara wrote:
>
> Trying to write a library that handles a lot of sensitive security tokens
> in std::string's, I queried some C++ fora about the possibilities of
> assuring these tokens not lingering about in memory.  Next to the usual
> half informed responses, the apparently most cluefull responses pointed out
> that anything I and others suggested I could do was either STL
> implementation specific or was something that the compiler would (and was
> in its right to) optimize away.
>
> Given that this is apparently a rather hard problem, and given that I'm
> not that deeply into the subject that I could propose a solidified solution
> for this issue,  rather than proposing one or multiple likely stupid
> proposals, I would just like to drop the problem for others with a solid
> understanding of the internals of the standard libraries and the
> optimization freedoms of compilers to think about.
>
> Could we think of any library proposal that would allow standard
> containers to optionally get securely wiped, without the compiler legally
> optimizing away the actual wiping  ?
>
> Rob
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_394_1127132709.1406173689644
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">None of the answers so far are taking into account the sec=
urity problems on common general-purpose OSes with memory safety. "Wiping" =
memory before deallocation is simply not enough.<div><br></div><div>General=
 purpose OSes can use a virtual memory system to move physical pages around=
 in memory, to disk, etc. Just because you clear some data doesn't mean tha=
t the OS didn't already make copies of the data elsewhere in RAM or on disk=
.. Many OSes provide some calls to "lock" virtual pages disallowing any such=
 copies or ensuring that the original copied-from pages are cleared by the =
OS after copy. Using these usually incurs some kind of performance overhead=
 (across all processes) or requires special process privileges.</div><div><=
br></div><div>An STL allocator wouldn't just want to clear memory but also =
ensure that all "secure" allocations come out of a pool of pages that are p=
roperly protected. It would essentially be a separate heap/free-store just =
for secure block allocations.</div><div><br></div><div>Given that not all p=
latforms have these features available, or are available with different con=
ditions or limitations, or that they work in different ways, standardizing =
them may be a little difficult. Possibly worth it, but a bit more than just=
 a new allocator or container.</div><div><br>On Tuesday, July 22, 2014 12:3=
5:40 AM UTC-7, pibara wrote:<blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><d=
iv dir=3D"ltr"><div style=3D"font-family:garamond,serif">Trying to write a =
library that handles a lot of sensitive security tokens in std::string's, I=
 queried some C++ fora about the possibilities of assuring these tokens not=
 lingering about in memory. &nbsp;Next to the usual half informed responses=
, the apparently most cluefull responses pointed out that anything I and ot=
hers suggested I could do was either STL implementation specific or was som=
ething that the compiler would (and was in its right to) optimize away.</di=
v>
<div style=3D"font-family:garamond,serif"><br></div><div style=3D"font-fami=
ly:garamond,serif">Given that this is apparently a rather hard problem, and=
 given that I'm not that deeply into the subject that I could propose a sol=
idified solution for this issue, &nbsp;rather than proposing one or multipl=
e likely stupid proposals, I would just like to drop the problem for others=
 with a solid understanding of the internals of the standard libraries and =
the optimization freedoms of compilers to think about. &nbsp;</div>
<div style=3D"font-family:garamond,serif"><br></div><div style=3D"font-fami=
ly:garamond,serif">Could we think of any library proposal that would allow =
standard containers to optionally get securely wiped, without the compiler =
legally optimizing away the actual wiping &nbsp;?</div>
<div style=3D"font-family:garamond,serif"><br></div><div style=3D"font-fami=
ly:garamond,serif">Rob</div></div>
</blockquote></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_394_1127132709.1406173689644--

.


Author: David Krauss <potswa@gmail.com>
Date: Thu, 24 Jul 2014 12:12:48 +0800
Raw View
Security always requires end-to-end, holistic engineering. A locked page on=
 a machine running inside a VM will still be written to disk when the hyper=
visor suspends it.

The best solution is to encrypt the (physical) hard drive, including the VM=
 backing store. OS support varies. Also, don't connect the machine to the I=
nternet!

It might be nice if POSIX offered queries about hardware-level security, so=
 the kernel could let you know if it detects that your CPU silicon has an M=
MU bug. IMHO C++ goes far enough already in its custom memory management, n=
ot to mention the ability to derive from std::string. A separate datatype w=
ith non-public inheritance is probably appropriate, to avoid accidental tre=
atment of secure data as insecure.


On 2014-07-24, at 11:48 AM, Sean Middleditch <sean.middleditch@gmail.com> w=
rote:

> None of the answers so far are taking into account the security problems =
on common general-purpose OSes with memory safety. "Wiping" memory before d=
eallocation is simply not enough.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.


Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Thu, 24 Jul 2014 02:21:21 -0700 (PDT)
Raw View
------=_Part_243_720618229.1406193681198
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wednesday, July 23, 2014 8:50:02 AM UTC+2, David Krauss wrote:
>
> The implementation is free to leave the null terminator uninitialized=20
> until c_str() is called, but this doesn=E2=80=99t apply to data().
>

Is it?
http://www.cplusplus.com/reference/string/string/data/ says they're=20
equivalent.=20

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_243_720618229.1406193681198
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, July 23, 2014 8:50:02 AM UTC+2, David Krauss=
 wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-wrap=
:break-word"><div>The implementation is free to leave the null terminator u=
ninitialized until <font face=3D"Courier">c_str()</font> is called, but thi=
s doesn=E2=80=99t apply to <font face=3D"Courier">data()</font>.</div></div=
></blockquote><div><br></div><div>Is it?</div><div>http://www.cplusplus.com=
/reference/string/string/data/ says they're equivalent.&nbsp;</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_243_720618229.1406193681198--

.


Author: David Krauss <potswa@gmail.com>
Date: Thu, 24 Jul 2014 17:37:02 +0800
Raw View
--Apple-Mail=_9C75D9AE-1019-4172-852F-A53C3A74651E
Content-Type: text/plain; charset=ISO-8859-1


On 2014-07-24, at 5:21 PM, Olaf van der Spek <olafvdspek@gmail.com> wrote:

> On Wednesday, July 23, 2014 8:50:02 AM UTC+2, David Krauss wrote:
> The implementation is free to leave the null terminator uninitialized until c_str() is called, but this doesn't apply to data().
>
> Is it?
> http://www.cplusplus.com/reference/string/string/data/ says they're equivalent.

Is that an appeal to authority? Who even edits that site? It's clickbait.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--Apple-Mail=_9C75D9AE-1019-4172-852F-A53C3A74651E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;07&ndash;24, at 5:21 PM, Olaf van der Spek &lt;<a href=3D"mailto:olaf=
vdspek@gmail.com">olafvdspek@gmail.com</a>&gt; wrote:</div><br class=3D"App=
le-interchange-newline"><blockquote type=3D"cite"><div dir=3D"ltr">On Wedne=
sday, July 23, 2014 8:50:02 AM UTC+2, David Krauss wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div style=3D"word-wrap:break-word">The impleme=
ntation is free to leave the null terminator uninitialized until <font face=
=3D"Courier">c_str()</font> is called, but this doesn&rsquo;t apply to <fon=
t face=3D"Courier">data()</font>.</div></blockquote><div><br></div><div>Is =
it?</div><div><a href=3D"http://www.cplusplus.com/reference/string/string/d=
ata/">http://www.cplusplus.com/reference/string/string/data/</a> says they'=
re equivalent.&nbsp;</div></div></blockquote><br></div><div>Is that an appe=
al to authority? Who even edits that site? It&rsquo;s clickbait.</div><div>=
<br></div></body></html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_9C75D9AE-1019-4172-852F-A53C3A74651E--

.


Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Thu, 24 Jul 2014 11:43:46 +0200
Raw View
On Thu, Jul 24, 2014 at 11:37 AM, David Krauss <potswa@gmail.com> wrote:
>
>
> On 2014=E2=80=9307=E2=80=9324, at 5:21 PM, Olaf van der Spek <olafvdspek@=
gmail.com> wrote:
>
> On Wednesday, July 23, 2014 8:50:02 AM UTC+2, David Krauss wrote:
>>
>> The implementation is free to leave the null terminator uninitialized un=
til c_str() is called, but this doesn=E2=80=99t apply to data().
>
>
> Is it?
> http://www.cplusplus.com/reference/string/string/data/ says they're equiv=
alent.
>
>
> Is that an appeal to authority?

I know, I know, I should refer to the actual standard...

> Who even edits that site?

I've got no idea. Haven't been able to find any names.

> It=E2=80=99s clickbait.
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the Go=
ogle Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.=
org/d/topic/std-proposals/e9S7xwhHg3k/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to std-p=
roposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at http://groups.google.com/a/isocpp.org/group/std-propo=
sals/.




--=20
Olaf

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.


Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 24 Jul 2014 13:12:16 +0300
Raw View
On 24 July 2014 12:43, Olaf van der Spek <olafvdspek@gmail.com> wrote:
>> Is that an appeal to authority?
>
> I know, I know, I should refer to the actual standard...

[string.accessors] specifies that .c_str() and .data() have identical effects.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.


Author: David Krauss <potswa@gmail.com>
Date: Thu, 24 Jul 2014 18:19:11 +0800
Raw View
--Apple-Mail=_3A076C21-A260-4A49-99D1-BED340358A8F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2014-07-24, at 6:12 PM, Ville Voutilainen <ville.voutilainen@gmail.com> =
wrote:

> [string.accessors] specifies that .c_str() and .data() have identical eff=
ects.

Well, it constrains the two functions identically. But, it does require dat=
a() to initialize the null terminator (tricky spec, mind the range), which =
is surprising and may be a defect. I'd certainly expect data() to be a simp=
le one-instruction deal like &s[0].

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--Apple-Mail=_3A076C21-A260-4A49-99D1-BED340358A8F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;07&ndash;24, at 6:12 PM, Ville Voutilainen &lt;<a href=3D"mailto:vill=
e.voutilainen@gmail.com">ville.voutilainen@gmail.com</a>&gt; wrote:</div><b=
r class=3D"Apple-interchange-newline"><blockquote type=3D"cite">[string.acc=
essors] specifies that .c_str() and .data() have identical effects.<br></bl=
ockquote><div><br></div><div>Well, it constrains the two functions identica=
lly. But, it does require <font face=3D"Courier">data()</font> to initializ=
e the null terminator (tricky spec, mind the range), which is surprising an=
d may be a defect. I&rsquo;d certainly expect <font face=3D"Courier">data()=
</font> to be a simple one-instruction deal like <font face=3D"Courier">&am=
p;s[0]</font>.</div><div><br></div></div></body></html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_3A076C21-A260-4A49-99D1-BED340358A8F--

.


Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 24 Jul 2014 13:25:24 +0300
Raw View
On 24 July 2014 13:19, David Krauss <potswa@gmail.com> wrote:
>
> On 2014=E2=80=9307=E2=80=9324, at 6:12 PM, Ville Voutilainen <ville.vouti=
lainen@gmail.com>
> wrote:
>
> [string.accessors] specifies that .c_str() and .data() have identical
> effects.
>
>
> Well, it constrains the two functions identically. But, it does require
> data() to initialize the null terminator (tricky spec, mind the range),
> which is surprising and may be a defect. I=E2=80=99d certainly expect dat=
a() to be a
> simple one-instruction deal like &s[0].


data() can be a one-instruction deal, as long as string-modifying operation=
s and
constructors already make sure that the terminator is initialized.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.


Author: Thiago Macieira <thiago@macieira.org>
Date: Thu, 24 Jul 2014 08:02:40 -0700
Raw View
On Thursday 24 July 2014 11:43:46 Olaf van der Spek wrote:
> > Who even edits that site?
>
> I've got no idea. Haven't been able to find any names.

WHOIS data shows a person in California. Domain registered in 1999.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.


Author: dr.al.k.lisch@googlemail.com
Date: Sat, 9 Aug 2014 11:01:54 -0700 (PDT)
Raw View
------=_Part_962_1053994974.1407607314427
Content-Type: text/plain; charset=UTF-8



> Could we think of any library proposal that would allow standard
> containers to optionally get securely wiped, without the compiler legally
> optimizing away the actual wiping  ?
>

Back to the original question: The request could basically be solved by
something like this:

template<typename OutputIterator>
void wipe(OutputIterator it, OutputIterator end) {
    // exposition only, the implementation is required to make
    // sure that this won't get optimized away
    while (it != end) {
        *it = /* implementation-defined */;
        ++it;
    }
}

I think having something like this in the stdlib would be a *very* good
idea.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_962_1053994974.1407607314427
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div style=3D"font-family:garamond,serif">Could we think of any li=
brary proposal that would allow standard containers to optionally get secur=
ely wiped, without the compiler legally optimizing away the actual wiping &=
nbsp;?</div></div></blockquote><div><br>Back to the original question: The =
request could basically be solved by something like this:<br><br><div class=
=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-colo=
r: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: b=
reak-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span=
 style=3D"color: #008;" class=3D"styled-by-prettify">template</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">typename</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #606;" class=3D"styled-by-prettify">OutputIterator</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">&gt;</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;"=
 class=3D"styled-by-prettify">void</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> wipe</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">(</span><span style=3D"color: #606;" class=3D"styled-by-=
prettify">OutputIterator</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> it</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #606;" class=3D"styled-by-prettify">OutputItera=
tor</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">end</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"></span><br><code class=3D"prettyprint"><span style=
=3D"color: #000;" class=3D"styled-by-prettify">&nbsp; &nbsp; </span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify">// exposition only, the =
implementation is required to make<br>&nbsp;&nbsp;&nbsp; // sure that this =
won't get optimized away<br></span></code><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><code class=3D"prettyprint"><span style=3D"color: =
#000;" class=3D"styled-by-prettify">&nbsp; &nbsp; </span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify">while (it !=3D end) {<br></span></c=
ode></span><span style=3D"color: #000;" class=3D"styled-by-prettify"><code =
class=3D"prettyprint"><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"><code class=3D"prettyprint"><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">&nbsp; &nbsp; </span></code></span></code></span><code clas=
s=3D"prettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettify"=
>&nbsp; &nbsp; </span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"></span></code>*it =3D /* implementation-defined */;<br><code class=3D"=
prettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettify">&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ++it;</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"></span></code><code class=3D"prettyprint"=
><span style=3D"color: #000;" class=3D"styled-by-prettify"></span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"></span></code><br><code cl=
ass=3D"prettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettif=
y">&nbsp; &nbsp; </span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify">}<br>}</span></code><span style=3D"color: #000;" class=3D"styled-by-=
prettify"></span></div></code></div><br>I think having something like this =
in the stdlib would be a <b>very</b> good idea.<br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_962_1053994974.1407607314427--

.


Author: Ross Smith <rosss@pharos.co.nz>
Date: Mon, 11 Aug 2014 09:03:34 +1200
Raw View
On 2014-08-10 06:01, dr.al.k.lisch@googlemail.com wrote:
>
>     Could we think of any library proposal that would allow standard
>     containers to optionally get securely wiped, without the compiler
>     legally optimizing away the actual wiping  ?
>
>
> Back to the original question: The request could basically be solved by
> something like this:
>
> |
> template<typenameOutputIterator>
> voidwipe(OutputIteratorit,OutputIteratorend){
> |// exposition only, the implementation is required to make
>      // sure that this won't get optimized away
> ||while (it != end) {
> |||||||*it = /* implementation-defined */;
> |        ++it;|||
> |}
> }|
> |
>
> I think having something like this in the stdlib would be a *very* good
> idea.

Rather than leaving the wipe value implementation defined, it might be
better to have something like a "std::secure_fill()" algorithm, with
interface and semantics the same as std::fill(), apart from the
additional security requirement.

Simply requiring the compiler not to optimize the code away would not
be enough by itself; you would also need to add implicit memory
barriers before and after the secure_fill() call (or an
acquire/release pair). We're assuming the fill loop doesn't touch
anything used by nearby code (that's why it's in danger of being
optimized out of existence), so the compiler might feel free to
move code from after the loop to before it (opening a potential
security hole) without the barriers.

Ross Smith


--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.


Author: Thiago Macieira <thiago@macieira.org>
Date: Sun, 10 Aug 2014 18:25:10 -0300
Raw View
On Monday 11 August 2014 09:03:34 Ross Smith wrote:
> Simply requiring the compiler not to optimize the code away would not
> be enough by itself; you would also need to add implicit memory
> barriers before and after the secure_fill() call (or an
> acquire/release pair). We're assuming the fill loop doesn't touch
> anything used by nearby code (that's why it's in danger of being
> optimized out of existence), so the compiler might feel free to
> move code from after the loop to before it (opening a potential
> security hole) without the barriers.

As discussed in this thread, secure filling after use is not enough. You need
to securely allocate the memory so it is memory-locked and won't get swapped
out.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.