220 40448 <171c3741-7ebf-4383-83eb-ed68b08b10b2@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: florian.csdt@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: more security concerns Date: Tue, 9 Oct 2018 07:12:37 -0700 (PDT) Lines: 349 Approved: news@gmane.org Message-ID: <171c3741-7ebf-4383-83eb-ed68b08b10b2@isocpp.org> References: <94d79dd7-ba3b-4bf8-91ed-e5dc02b33670@isocpp.org> <199794e8-8362-489b-818f-ab6c510c5c84@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2038_367397919.1539094357450" X-Trace: blaine.gmane.org 1539094234 29314 195.159.176.226 (9 Oct 2018 14:10:34 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 9 Oct 2018 14:10:34 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBC26HM4V3MIRBVXO6LOQKGQE4UH74WI@isocpp.org Tue Oct 09 16:10:29 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw1-f70.google.com ([209.85.161.70]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1g9siT-0007UU-JN for gclcip-std-proposals@m.gmane.org; Tue, 09 Oct 2018 16:10:29 +0200 Original-Received: by mail-yw1-f70.google.com with SMTP id v132-v6sf915716ywb.15 for ; Tue, 09 Oct 2018 07:12:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=R7xrIBZ7iBTwiNbFOttgw4M8BhQ3GU2oBf5tY0x5b44=; b=Mu9erVeZgq4y4/9X6kQidR2VbFoWYRx/KDBwxoA66CfW3gDXw4d3bEEZNW08uX17n8 cCr+R3g1FsKbJ73BjbcTQBaae3VXmXlUVr5lOwktotDtcpC4edMfaqVHaZhEVvJnbQX3 jgcIFhNxvVMvNO2mdvBHd9/JjN8KWPUeXVF2PswvgVZK7UecRpRZXpVTzLBW7bTRYOpp iVFhfb6sEOJ7Lik9p0XNtuQbiVB26t27LfVl+/YmWr7oNWMFNcv92c0aITA1JHpXihyt hLDBJbFQam6g+8UYsTMM+omazu2neGB+L6869RMcbnuKrM7gYne9ij4U+86gTDzH/NDC BLqA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=R7xrIBZ7iBTwiNbFOttgw4M8BhQ3GU2oBf5tY0x5b44=; b=lHFjKJu5TGHSoZ+LbypVL3bBWum4TEsvTuPKQcQ6rrX43GkAQ4qoZ/LlrBHWhIur3Q pPG/+JbcRffDoqhFDhcSKDBj6b8y+PZqHtsWLe5R/B7pIOQugYUohL9K6/QBRnJin/2w D8+VwsNncDMoUSknDNXNaTVWbRx/xwL7RO29N+2PoNz+hQGT+QHw7ZK11oZgS+eqRrgJ zh9E/WCa+/SK5NrCAHzb6dlzRvHVAUuQcJNR9SsmJna7DoVT7pW5/cVPcm4u/a2r8JJL vRNWQO/GfgACKtKHRN4L1Go7xqfIO3l2ITbcFD0QGP1+bu/eBld9GYnNIt0jN34bO0Mp X6UQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:x-spam-checked-in-group:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=R7xrIBZ7iBTwiNbFOttgw4M8BhQ3GU2oBf5tY0x5b44=; b=gLl6l4ANZhuxYXB1bBNRpZ3navcXvKj95e+7KW09xbyUQwAnVOWYAvUYRPGIuAM68Q lxwNg6B2EBgUMLEeFLUuzDhh0JHKQ1pGlQKfEKxWUVCkypUbXh++lKBDgc8R9hStL0sb RheoZLq2iCwNGTD2oDdOF1xXl5iuZQPe1rAfL4YA3FKuTzi2Xr/7QJEPjPGEub5peoZo pDt74Dr5Ouo5sej/tpilYM8049eK6ZVusUXX9Mb/IrXmbhainpB8kqTRiqYNXFum4rG8 j5ib7dwQExfOiOJM+ZtL+Eu7B3WQlcxZrBknT+El2+GdQ3PbKzZn7b/UIhXXIRknJo3x oiCQ== X-Gm-Message-State: ABuFfog7hvjulNjDLNgiD868meI99OXMqMpPru1x6FHJ3n8Clkg2SkC0 v6cN3ZPvpbt8MKcU0X3qRlb4oA== X-Google-Smtp-Source: ACcGV63mwG/pdbciv6W8k+eXX6n4D99JeH3BC97PhroNzfEClCJPmedFlnoDCvn3+JbFKfw4mJ8Rhw== X-Received: by 2002:a25:ba50:: with SMTP id z16-v6mr13847391ybj.18.1539094359563; Tue, 09 Oct 2018 07:12:39 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a81:9157:: with SMTP id i84-v6ls1344717ywg.12.gmail; Tue, 09 Oct 2018 07:12:38 -0700 (PDT) X-Received: by 2002:a0d:dd42:: with SMTP id g63-v6mr306775ywe.2.1539094357890; Tue, 09 Oct 2018 07:12:37 -0700 (PDT) In-Reply-To: X-Original-Sender: florian.csdt@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:40448 Archived-At: ------=_Part_2038_367397919.1539094357450 Content-Type: multipart/alternative; boundary="----=_Part_2039_335946979.1539094357450" ------=_Part_2039_335946979.1539094357450 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Le mardi 9 octobre 2018 15:54:35 UTC+2, Miguel Ojeda a =C3=A9crit : > > On Tue, Oct 9, 2018 at 2:56 PM > wrote:= =20 > >=20 > >=20 > > Le mardi 9 octobre 2018 14:42:10 UTC+2, Miguel Ojeda a =C3=A9crit :=20 > >>=20 > >> Hi Florian,=20 > >>=20 > >> On Tue, Oct 9, 2018 at 2:24 PM wrote:=20 > >> >=20 > >> > For your second point, I didn't think about it yet. So I didn't take= =20 > it into consideration when I proposed the [[undead]] attribute. But if yo= ur=20 > goal is security, then you would also need to take into consideration thi= s.=20 > >> > Let's imagine an attribute [[secret]].=20 > >> > Every object marked as [[secret]] will be cleaned before function=20 > exit.=20 > >> > This cleaning means set to zero every location that still contains= =20 > the object (known to the compiler).=20 > >>=20 > >> This sounds very similar to secure_val, but as a variable attribute.= =20 > >=20 > >=20 > > Yes it is similar. But I think attribute is more appropriate because=20 > those security issues are not about C++: in order to read a destroyed=20 > value, you need to use undefined behavior somehow.=20 > >=20 > > I am not sure what you mean by "are not about C++" or by "reading a=20 > destroyed value". Do you mean you want to have compiler support so=20 > that other languages (like C) can take advantage of it?=20 > No, I mean these security issues arise beyond the scope of C++. As far as C++ is concerned, you cannot access a destroyed value (so the=20 secret remains secret). Any attempt in doing that leads to undefined behaviours: meaning the result= =20 does not depends on C++ semantic anymore. So if every single undefined behavior would crash the program instant=20 (which is actually valid), there would be no secret leaking issue at all. That's what I mean when I say it is not about C++. I don't necessarily want to have it for other languages (but it would be=20 good if we do). =20 > > Note that there are C++-only attributes; and that, anyway, it would be=20 > nice to have a concrete use case (e.g. secure_val) where such features=20 > could be used.=20 > > >>=20 > >>=20 > >> > Also, in order to not deduce the secret from other temporaries, any= =20 > value depending on a [[secret]] object is also marked implicitly as=20 > [[secret]].=20 > >> >=20 > >> > This does not address cache persistency, but it can be covered if th= e=20 > [[secret]] can take an optional argument to ensure cache lines related to= =20 > this object are flushed (done by the compiler).=20 > >> >=20 > >> > With this, you start to have a pretty strong security plan for stack= =20 > objects. But the heap objects cannot be marked as secret. So for that,=20 > maybe you could mark the delete statement as [[secret]] and let the=20 > compiler do the same thing for heap objects.=20 > >>=20 > >> I would say users should not care where or how the value is stored.=20 > >> Having to mark delete statements with an attribute seems odd.=20 > >=20 > >=20 > > The problem is, when you create an object on the heap, on don't really= =20 > own the object. that's why it needs a special treatment.=20 > > Maybe marking the pointer type as [[secret]] could solve the issue.=20 > > Yes, exactly, that is why secure_val is a template: in my view, it has=20 > to be applied the type; not on statements (Daniel's original proposal)=20 > or variables (your initial [[secret]] proposal). If you create a type=20 > attribute, then it could be used itself to implement (part of)=20 > secure_val.=20 > true. =20 > > > If you delete a [[secret]] pointer, then the compiler needs to ensure= =20 > every location is cleaned afterwards.=20 > >=20 > >>=20 > >> As a=20 > >> user, I would simply prefer to be able to mark my type T with=20 > >> [[secret]] and then *that* could be put into the heap. That is the=20 > >> reason I went for a template, because it looked natural to wrap values= =20 > >> with it:=20 > >>=20 > >> std::secure_val my_very_secret_number;=20 > >> std::secure_val my_private_key;=20 > >>=20 > >> etc.=20 > >=20 > >=20 > > The problem with your template approach is: you don't have the cascade= =20 > of the secret property, so temporaries depending on your secure_val will= =20 > not be cleaned.=20 > > It depends. Note that the accesses to the secret value must go through=20 > access(). This is intended so that code inside that block may be=20 > treated specially by the compiler. The examples given in the proposal=20 > about how this can be used are encryption (compiler support not needed=20 > in principle), disabling speculation (compiler support needed), etc.=20 > Your encryption use case actually needs compiler support if your compiler= =20 is "smart" enough to duplicate your object location. =20 > > > Also, your template is not safely implementable in C++: you need=20 > cooperation from the compiler in the same way as with the attribute,=20 > because of the possible mutliple locations of your object.=20 > >=20 > > Of course it isn't, that is the whole point of secure_val. :-)=20 > > Let me put it this way: I would love secure_val to be implementable in=20 > C++ (or at least part of it, e.g. the auto-clear [[secret]] part that=20 > you are discussing). However, it is not clear yet how many things we=20 > would need to add to the language or how. Some things, like=20 > Spectre-class vulnerabilities, are still being researched. Therefore,=20 > I suggested secure_val first to make the most common use case=20 > concrete, and at the same time give developers a simple solution to=20 > it. Since secure_val does not force almost anything on the vendors=20 > (except the auto-clear), it can be updated to provide further=20 > guarantees as time goes on.=20 > The auto-clear does require compiler support if you want a proper/safe=20 implementation of it. But you're right: it can be done incrementally. =20 Cheers, Florian --=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. To view this discussion on the web visit https://groups.google.com/a/isocpp= ..org/d/msgid/std-proposals/171c3741-7ebf-4383-83eb-ed68b08b10b2%40isocpp.or= g. ------=_Part_2039_335946979.1539094357450 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Le mardi 9 octobre 2018 15:54:35 UTC+2, Miguel Oje= da a =C3=A9crit=C2=A0:
On Tue, = Oct 9, 2018 at 2:56 PM <floria...@gmail.com> wrote:
>
>
> Le mardi 9 octobre 2018 14:42:10 UTC+2, Miguel Ojeda a =C3=A9crit = :
>>
>> Hi Florian,
>>
>> On Tue, Oct 9, 2018 at 2:24 PM <floria...@gmail.com&= gt; wrote:
>> >
>> > For your second point, I didn't think about it yet. S= o I didn't take it into consideration when I proposed the [[undead]] at= tribute. But if your goal is security, then you would also need to take int= o consideration this.
>> > Let's imagine an attribute [[secret]].
>> > Every object marked as [[secret]] will be cleaned before = function exit.
>> > This cleaning means set to zero every location that still= contains the object (known to the compiler).
>>
>> This sounds very similar to secure_val, but as a variable attr= ibute.
>
>
> Yes it is similar. But I think attribute is more appropriate becau= se those security issues are not about C++: in order to read a destroyed va= lue, you need to use undefined behavior somehow.
>

I am not sure what you mean by "are not about C++" or by &quo= t;reading a
destroyed value". Do you mean you want to have compiler support so
that other languages (like C) can take advantage of it?

No, I mean these security issues arise= beyond the scope of C++.
As far as C++ is concerned, you cannot = access a destroyed value (so the secret remains secret).
Any atte= mpt in doing that leads to undefined behaviours: meaning the result does no= t depends on C++ semantic anymore.
So if every single undefined b= ehavior would crash the program instant (which is actually valid), there wo= uld be no secret leaking issue at all.

That's = what I mean when I say it is not about C++.

I don&= #39;t necessarily want to have it for other languages (but it would be good= if we do).
=C2=A0

Note that there are C++-only attributes; and that, anyway, it would be
nice to have a concrete use case (e.g. secure_val) where such features
could be used.

>>
>>
>> > Also, in order to not deduce the secret from other tempor= aries, any value depending on a [[secret]] object is also marked implicitly= as [[secret]].
>> >
>> > This does not address cache persistency, but it can be co= vered if the [[secret]] can take an optional argument to ensure cache lines= related to this object are flushed (done by the compiler).
>> >
>> > With this, you start to have a pretty strong security pla= n for stack objects. But the heap objects cannot be marked as secret. So fo= r that, maybe you could mark the delete statement as [[secret]] and let the= compiler do the same thing for heap objects.
>>
>> I would say users should not care where or how the value is st= ored.
>> Having to mark delete statements with an attribute seems odd.
>
>
> The problem is, when you create an object on the heap, on don'= t really own the object. that's why it needs a special treatment.
> Maybe marking the pointer type as [[secret]] could solve the issue= ..

Yes, exactly, that is why secure_val is a template: in my view, it has
to be applied the type; not on statements (Daniel's original propos= al)
or variables (your initial [[secret]] proposal). If you create a type
attribute, then it could be used itself to implement (part of)
secure_val.

true.
=C2=A0

> If you delete a [[secret]] pointer, then the compiler needs to ens= ure every location is cleaned afterwards.
>
>>
>> As a
>> user, I would simply prefer to be able to mark my type T with
>> [[secret]] and then *that* could be put into the heap. That is= the
>> reason I went for a template, because it looked natural to wra= p values
>> with it:
>>
>> =C2=A0 std::secure_val<int> my_very_secret_number;
>> =C2=A0 std::secure_val<char [N]> my_private_key;
>>
>> etc.
>
>
> The problem with your template approach is: you don't have the= cascade of the secret property, so temporaries depending on your secure_va= l will not be cleaned.

It depends. Note that the accesses to the secret value must go through
access(). This is intended so that code inside that block may be
treated specially by the compiler. The examples given in the proposal
about how this can be used are encryption (compiler support not needed
in principle), disabling speculation (compiler support needed), etc.

Your encryption use case actually need= s compiler support if your compiler is "smart" enough to duplicat= e your object location.
=C2=A0

> Also, your template is not safely implementable in C++: you need c= ooperation from the compiler in the same way as with the attribute, because= of the possible mutliple locations of your object.
>

Of course it isn't, that is the whole point of secure_val. :-)

Let me put it this way: I would love secure_val to be implementable in
C++ (or at least part of it, e.g. the auto-clear [[secret]] part that
you are discussing). However, it is not clear yet how many things we
would need to add to the language or how. Some things, like
Spectre-class vulnerabilities, are still being researched. Therefore,
I suggested secure_val first to make the most common use case
concrete, and at the same time give developers a simple solution to
it. Since secure_val does not force almost anything on the vendors
(except the auto-clear), it can be updated to provide further
guarantees as time goes on.

The auto-clear does require compiler s= upport if you want a proper/safe implementation of it.
But you= 9;re right: it can be done incrementally.
=C2=A0
Ch= eers,
Florian

--
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/171c3741-7ebf-4383-83eb-ed68b08b10b2= %40isocpp.org.
------=_Part_2039_335946979.1539094357450-- ------=_Part_2038_367397919.1539094357450-- .