220 40447 article Path: news.gmane.org!.POSTED!not-for-mail From: Miguel Ojeda Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: more security concerns Date: Tue, 9 Oct 2018 15:54:22 +0200 Lines: 120 Approved: news@gmane.org Message-ID: 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: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1539093149 6716 195.159.176.226 (9 Oct 2018 13:52:29 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 9 Oct 2018 13:52:29 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDRZHGH43YJRBGXG6LOQKGQEK4OGDWA@isocpp.org Tue Oct 09 15:52:25 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-lf1-f71.google.com ([209.85.167.71]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1g9sQy-0001e0-CP for gclcip-std-proposals@m.gmane.org; Tue, 09 Oct 2018 15:52:24 +0200 Original-Received: by mail-lf1-f71.google.com with SMTP id c20-v6sf206291lfi.3 for ; Tue, 09 Oct 2018 06:54:35 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1539093275; cv=pass; d=google.com; s=arc-20160816; b=XUMbb0aGR8X0M7aFOhyIH2yrJMusjp/Gb5LT5lGIz0aMsWgovWqmLHhQag08tfAjWL DSckWtghzjWgULgjEI5kNFK+SsZuYxU1R9ZnwJmTQeKlGERfxCYxqANxzJauWpRmlzm3 VckqgHCiIb6BbBSbRnm3xnswOss1I0PrOQL+JG+D0kBAIvQ9UWcCoLAa5e5NUSTr/7Ya g9CV5MAxf/z3SADVjXh8A4VbOoFRR711iDCRmtKdeWAV64RX8gt5fnKUg/cZT8bgZn2p SkcxyoMSGgi2G1MCPnr6kD8wfzpyUGo1DaLxOou5fusmgNC7pT0qwEWDBCOd4B2idWN6 EjtQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:content-transfer-encoding :to:subject:message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=u8FUKZMKvoeNKTwariu/xZurdA44bbGsvDTuSJ9VYLI=; b=iBG6xfyaN37oNbA6pdfUQ3UvbcGcnjqy+JIIOPF7pP7JoKymSwm9NgPQraBoyahlMA anxYCwogw+C4myvjscKWD7FMwZbWVpoOzTeTdavFwo+Npxl4e8HKLeVsFPKEGVFbYFfH G3hafkpEhljEpmrR2NhgANp4/ZTuT6oF9n+7xYXH+G2wPgnebnGt1HC5O7tr/J7bkkMI pALae7P1btAh4lcVsbL9LqHQWT49qSW99fXU0ZbS+NvvlFX0aAM9EjQWkUmcFvLS+xrK +VouM5/q3TPJdP4i6Ffl92wVFB9aklw8vRzJzk1AdVgwacSqJBOzWGq5rCG7OFbmYOGv oueQ== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=bQ9mgc5E; spf=pass (google.com: domain of miguel.ojeda.sandonis@gmail.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=miguel.ojeda.sandonis@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-transfer-encoding:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=u8FUKZMKvoeNKTwariu/xZurdA44bbGsvDTuSJ9VYLI=; b=wrMfng5ekEZFeubWGgWmDSd02U/huOmpy4duGmrNLnCx5RcFR5Ewy8Q9jUTVd6z0VK xTOyg9AfGQjK1J5C2gMuiQbWPIMu1urczJh8gYEBtPD7B+UNw8ajlLo8A9Yrjye4WIsi iwMD5qEwii85VUjkJsSKJWyy0BgCAsf2DTanNO0Qax7RrwD2PNroaBdIS8ajBsBo3xBt ykOZ/XWza7hVTC7Ysl1R9X+0YUzbpROMbD6Vic9NevjaZ6LRHDsEXHNSEHoE+KdpksPL glt1O0NXNKJhSQeGrv+NsYpx2iKEYG1KpoADtr4ImS1938iPg4VNeIK1isZYzOmRRP4R Fi3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-transfer-encoding:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=u8FUKZMKvoeNKTwariu/xZurdA44bbGsvDTuSJ9VYLI=; b=pJwVJK0JGR+ZPe8hWML7glDF60UYw87tgETHLhRMfqwvg4umPb0sTRxjIhYPmI4mjN IIPEBkmZlmwc50Naji3/E3RrrFqxAZT48d5tR1ETjatb71yXXxd7TIaZA5xti3UybHKO D63/0NO6KWYz+8WVWbCT7h+uQYEVMqe5yu1ZpnKOYz6Jd8zpC9Wn/fVV2LUWeD1rntdG VBXMvz8+4gj3wYHpmz4tQbRpmB+y0bz8NU/2HMhrBkY+c2DKZqiTOBLQ883pLU45JIVQ IhXS74fYHsLNMLAue/3Vt65Ggu2WDW5jtyQqRyL2r0kUFd1kTF0ruvE0+Dyy16mX1l1o OxH X-Gm-Message-State: ABuFfogklGRqRtMDrCcwqXway5YI4SC9skaDVCaeJbip+sMd6HQ/XRhY MHs+gHpaZgG+y20xd+JfInbUNg== X-Google-Smtp-Source: ACcGV62wTP24/nL1RwxPJf28+7A2A6Lbxk82OydZuB+VlFxYnaMtom61gyZk4ewoVByJuuYmL6jvow== X-Received: by 2002:a19:f60a:: with SMTP id x10-v6mr748518lfe.18.1539093275294; Tue, 09 Oct 2018 06:54:35 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a2e:4411:: with SMTP id r17-v6ls198572lja.17.gmail; Tue, 09 Oct 2018 06:54:33 -0700 (PDT) X-Received: by 2002:a2e:1615:: with SMTP id w21-v6mr17865595ljd.33.1539093273911; Tue, 09 Oct 2018 06:54:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1539093273; cv=none; d=google.com; s=arc-20160816; b=TJj2E9KBKgt8dWW0ptky9oR0rhGNk4zWXhC+v2idfaGrpcSdeCYtrkzOv2gBBT3NW9 zmZ1jAy+cFQW8gJ5m7hSRBIhSPv/m8SqtIwXyM+FRkyWwXmDRZOkEX9EYxVZcwSOqSmi 2ofEXy8Ko1fVFbvYapi95sovoTfdENwtt3QQuxCC+8L65y+cvBqpoouNyeyVCwN8N695 0bIN3IYnx6XY/RtIpL5mbzxGqh639r5q+yCxcfNPmuCSx2dqbhPLEcweeNTCAZe0G2+I L2PtgruIliiEHuEhI40Q7bEWrkO0C7c8WNwkD6HOYDPfrIxy9RREpKa4nH7lRDQmRehx eoww== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=i0UnfDOTki19EOUp4kTEFTOrx7coDjkklas4DwTe9HY=; b=eX4oIRE5INYHspygeCJPgmC12pCdjDjpKL8nLhoGGCljxLjJr1L/LOBkrfygph3F5h 5DOb25yYfLJBudNpO2hPhgz5IcTJAldNGNnBl6zmXxO/eQm3WgMwMlmef6i3T+YSaQ6m v3P06lnx5vdeySngdYFQP5Ios9zjzBftPn3l+QqVyXfrY+KMP9+g2q1gnpwRFmi+RXhf PYG0ug5mtD9ieGYXxfu8/1Zk1HCqT97WGTEFGigyPShmKb4KFutB7H6WnGMDdXEGn2Et /Z/LiHcnjGVA0/Y3IhzvXFmsn2gDgsrccUTTXM1d8IXiNxOCVY9vibs1oMS5R+DUfdkn qlWA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=bQ9mgc5E; spf=pass (google.com: domain of miguel.ojeda.sandonis@gmail.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=miguel.ojeda.sandonis@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Original-Received: from mail-sor-f65.google.com (mail-sor-f65.google.com. [209.85.220.65]) by mx.google.com with SMTPS id k5-v6sor3610024ljh.7.2018.10.09.06.54.33 for (Google Transport Security); Tue, 09 Oct 2018 06:54:33 -0700 (PDT) Received-SPF: pass (google.com: domain of miguel.ojeda.sandonis@gmail.com designates 209.85.220.65 as permitted sender) client-ip=209.85.220.65; X-Received: by 2002:a2e:9549:: with SMTP id t9-v6mr17925248ljh.94.1539093273421; Tue, 09 Oct 2018 06:54:33 -0700 (PDT) In-Reply-To: <199794e8-8362-489b-818f-ab6c510c5c84@isocpp.org> X-Original-Sender: miguel.ojeda.sandonis@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=bQ9mgc5E; spf=pass (google.com: domain of miguel.ojeda.sandonis@gmail.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=miguel.ojeda.sandonis@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=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:40447 Archived-At: On Tue, Oct 9, 2018 at 2:56 PM 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 wrote: >> > >> > For your second point, I didn't think about it yet. So I didn't take i= t into consideration when I proposed the [[undead]] attribute. But if your = goal is security, then you would also need to take into 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 attribute. > > > Yes it is similar. But I think attribute is more appropriate because thos= e security issues are not about C++: in order to read a destroyed value, yo= u need to use undefined behavior somehow. > I am not sure what you mean by "are not about C++" or by "reading a destroyed value". Do you mean you want to have compiler support so that other languages (like C) can take advantage of it? 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 temporaries, any va= lue depending on a [[secret]] object is also marked implicitly as [[secret]= ]. >> > >> > This does not address cache persistency, but it can be covered if the = [[secret]] can take an optional argument to ensure cache lines related to t= his object are flushed (done by the compiler). >> > >> > With this, you start to have a pretty strong security plan for stack o= bjects. But the heap objects cannot be marked as secret. So for 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 stored. >> 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 ow= n 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 proposal) or variables (your initial [[secret]] proposal). If you create a type attribute, then it could be used itself to implement (part of) secure_val. > If you delete a [[secret]] pointer, then the compiler needs to ensure eve= ry 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 wrap values >> with it: >> >> std::secure_val my_very_secret_number; >> std::secure_val 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_val 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. > Also, your template is not safely implementable in C++: you need cooperat= ion 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. Cheers, Miguel --=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/CANiq72mHdtv1H87QQWjRQzAa_BkCgr4SU9C2iOr7aJxGJJq= f%2Bw%40mail.gmail.com. .