220 40413 article Path: news.gmane.org!.POSTED!not-for-mail From: Daniel Gutson Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: more security concerns Date: Tue, 9 Oct 2018 07:41:06 -0300 Lines: 161 Approved: news@gmane.org Message-ID: References: <94d79dd7-ba3b-4bf8-91ed-e5dc02b33670@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000caf9840577c960e2" X-Trace: blaine.gmane.org 1539081555 21484 195.159.176.226 (9 Oct 2018 10:39:15 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 9 Oct 2018 10:39:15 +0000 (UTC) To: std-proposals Original-X-From: std-proposals+bncBDE3NBMV6UFBBUEL6LOQKGQEM6XTC7Q@isocpp.org Tue Oct 09 12:39:11 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-lj1-f198.google.com ([209.85.208.198]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1g9pPy-0005U7-Fu for gclcip-std-proposals@m.gmane.org; Tue, 09 Oct 2018 12:39:10 +0200 Original-Received: by mail-lj1-f198.google.com with SMTP id s75-v6sf339944lje.19 for ; Tue, 09 Oct 2018 03:41:21 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1539081681; cv=pass; d=google.com; s=arc-20160816; b=HXcHAuew55fzwscMTtzWqq7PgsWxZczHJL8msuIRNCV1X8UpFd1ghVhROB1RjyDOqh vbEVBorbbzlscl/UiEZZK1K/YuyXHHvYqGq61veobe4j9mOhYGIIJfUXYHYCWb/Cx1E7 q/x+2VF77JkAjTNfaqRm9xZefg++7irX/uZjKmCwrQftPOj/jxsk2wd+i0MJ1GmfYTIx TUk3te+oFBDuRKjJy6P35Eh/CFNyq534q4v/IDS8+OmV6rrm+5hNCtuYCn2mLnNnwnPF ohj7cQ/cumaDNDKURBZ4anGgeD22SDLLzuYkobDUj5FCNtz/6eOSxQBOCruoEJYa2PdD iDtQ== 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:to:subject:message-id:date :from:in-reply-to:references:mime-version:dkim-signature; bh=+YgP+gjp6ZjRldSwj7jPmKZb5lw/V9eBc8RqKVULJ9c=; b=TQksjgLasuEi9391AYjlno+u4UCdpEjdl+Gj4sP5i+k/9CMn6kj65qte4Kp7y8/tTe FFgI4L3lUDAKYS3qMESiLDGVXPwtriW0g2YS08c9RYfito3ZOLdspYxysii8GkUvG0bD WPT3Q6eq79XYSF0aT1l6SNEAS7M0mrpht2jHhSdmi5izeN+KampyM348/sou+c6x5AaF RVXQha80HmpahE8/HzPhO0uxxyk8+tMJGRGL50I/6dYAhCsqZyHSlvtgcZeVRJWiWL4R q8pNlxhbPOoPDU9DQ4Jv1+eXdg4EQi1cxx8NhPftIPhZDL5GTPvAXCyUHLTOl8CXXs2F TE5w== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=JayBaU0U; spf=pass (google.com: domain of danielgutson@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=danielgutson@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 :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=+YgP+gjp6ZjRldSwj7jPmKZb5lw/V9eBc8RqKVULJ9c=; b=EXFnYBz4OuTkckvNZKoYJ33ThFo/3dgAiEngy4yQVg6rPToilZsR1SRwEG22Fh1ta0 yw57OJvrpDUyQlMu2nlOi+Bo7kgzAB4VpkRi2LCs69RGv+dGzeJ9IxOc1ovG+ZOIzsHX Pa46o8bR+R32jlffWwTmFVMshIq3RswHhasNRygWV3IADoKJfBlduWnfHqV0kJn8SIjm nl7yVv52+qudNtx3Iakp07kcES3nzA9Z1BYU5kLjoJSKN6rLbyQx/uXlqT1YRRH0Atym MFDdFjGnWt1Xf84UUnYT/Kos9K/AIGplccfY7MGOw9ZeoKXK0S5P1ua0d6/WW857PIEz Z+nQ== 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: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=+YgP+gjp6ZjRldSwj7jPmKZb5lw/V9eBc8RqKVULJ9c=; b=l953yjq45Z5PFEOetBI3A0E3r1myiFwLbxx1tn4MDO3wkSqrafQJnsPUwUHIlegN40 p+VTbhUVkPE7AMHzC7AbgN4SqfYiUQGSIyRzmj+qqgmYwDAq+r5cUIZweVJRmqpd3hIG Meh4kgprP2iRIMrdGib/xpqFBVHMx1ip0WivTxGfPrlEXcaNbepsRhU0eqLC4AF42ESz 4HUoJYLWu9UQLUeXLFDpko+mLYpWp+ZyN5F3ow4lPq3hnmLbYLw4Lq8f93OkJgWEyA2G A4/2K2nPsKl8SLjsZxQLPkclklFoZlMiCy6uK/1RkEvH5vrckzhwNCPzY0wWhp6PFLHt IbnA== X-Gm-Message-State: ABuFfogks6jQzmcztrb7zNknztoW51u+z27/KShxRhfMJjTJ0dZ5jdE4 AGSTIYxGiJ1yGm0qqYT10UHLdA== X-Google-Smtp-Source: ACcGV62DGG5JMSxemDUMPZuzQfovnq3WsjsJ8ppAIPC/Kx3+wtI9DHzewIs0v26h9gfZZDjUyqoGgg== X-Received: by 2002:a19:d894:: with SMTP id r20-v6mr742410lfi.3.1539081681363; Tue, 09 Oct 2018 03:41:21 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a19:2a1b:: with SMTP id f27-v6ls68701lfl.17.gmail; Tue, 09 Oct 2018 03:41:20 -0700 (PDT) X-Received: by 2002:a19:2648:: with SMTP id m69-v6mr14555818lfm.78.1539081680240; Tue, 09 Oct 2018 03:41:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1539081680; cv=none; d=google.com; s=arc-20160816; b=W3IA+PNlzPzuTm886ut0uIglMvZe/LtowWtpAduyvEL5JvmPBVLQcoeaHnMmToB2U1 qlyms4tnspxUurmg/GYDk1toHjJV/Rhe8frhCGx7d+Qb4oyyM9OKS/yO1i4UOKoqr/+G HvYvn8ByYfVwJwA/uoGRomuFPKUaQY+j8231y8z13xnBLEnrDBC84fIRVIRoErOnIgKP r0lzJPgZYbZHcfzpVTBp7RVw3WmgXwZ7dunTQBuCVTmUvKSVi0acHOoUz8A3fO2rIon6 roitnp0t7KrFHHaY0TypS416e+xu5mTlPfFQ2JtckRjRmWBzRmj8mKlPatprpNPVwLl8 AprQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=qRy4oRanuZdFUJDcvzem6u1ebK3bXVorAWCGMQPxHes=; b=fHy+tGrg52F01R7TFkH+xzN/fqPhPfN+YXGSMj2ATnDkGTgE1A2rgeW1noIrkN+J52 ymlKSkyVL7YhtU2+v+jhZPnVlzTko9Fu2JAfJO/NlrzGaGdNTUCKPBjgMbmlRnAK2CHV n+fZOIIfMjOEV8/TxPIqn0JStKRtTmUsT08kU3GlxGoYI7lbxw8nihV6jOS6iWKglcX+ 9/8ewJ9pT54SgJ7HAIWPjuDEa4Zg2jEFtEc3yCdyJk+8MB8pYCdmXYWiWA955GMua0qF X1KzIrZtZ51XcpchBEuOevL5P5fWsa91UoskVk9hug3omWw4wRcQUz+yHYC0+nqjQLnE Xq+Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=JayBaU0U; spf=pass (google.com: domain of danielgutson@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=danielgutson@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Original-Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41]) by mx.google.com with SMTPS id w15-v6sor533082lfe.0.2018.10.09.03.41.20 for (Google Transport Security); Tue, 09 Oct 2018 03:41:20 -0700 (PDT) Received-SPF: pass (google.com: domain of danielgutson@gmail.com designates 209.85.220.41 as permitted sender) client-ip=209.85.220.41; X-Received: by 2002:a19:cb09:: with SMTP id b9-v6mr15782590lfg.117.1539081679598; Tue, 09 Oct 2018 03:41:19 -0700 (PDT) In-Reply-To: X-Original-Sender: danielgutson@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=JayBaU0U; spf=pass (google.com: domain of danielgutson@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=danielgutson@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:40413 Archived-At: --000000000000caf9840577c960e2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable El mar., 9 oct. 2018 5:18, escribi=C3=B3: > Le mardi 9 octobre 2018 04:24:53 UTC+2, Daniel Gutson a =C3=A9crit : >> >> >> >> El lun., 8 oct. 2018 21:38, escribi=C3=B3: >> >>> That could be easily broken if someone replaced memset() with another >>> super_memset() function or similar which did more than one write. How w= ould >>> the compiler know which write inside of the memset() function it has to >>> keep? Would it only work for memset and assignments? I don't like the i= dea >>> of an attribute that only works for memset() but not other functions. >>> >> >> That's why I'm struggling to explain that this attribute is >> statement-wise rather than for annotating function *calls* only >> > > Your very first example is not suited for an attribute on a statement, bu= t > for an attribute on the object itself because you don't know (and will > never know) where the object is (in register? in memory? both?) and on > which location the last assignment is done. > Even if you could force the assignment both in register and in memory, ar= e > you sure the assignment in register has overridden the right register? > Are you saying that the object may undergo internal copies for optimization purposes (e.g. if it is in a register it may be copied to other registers as a temporal)? It could also be arithmetically operated in other registers which would still turn it recoverable by applying the reverse operation. Hm. Is that what you are saying? So enforcing that the last assignment is done gives you almost nothing in > that case (That's why I proposed the [[undead]] attribute, but alternativ= es > are fine). > > However, for other purposes I think it's fine (the memset example on heap > memory) and here I completely agree that an attribute on the statement is > the right way to do (I just disagree on the name of of the attribute > because I find it misleading). > I also want to mention here, that it is already possible to do it with > inline asm (not standard). > > -- > 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. > To view this discussion on the web visit > https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e7edc1e3-a9b= 3-421c-a72f-623d6c34b104%40isocpp.org > > . > --=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/CAFdMc-0-p7rOo3MYrfa%2Bx_zc21h58fZb_Qt5a1g6ocasC= qyJXw%40mail.gmail.com. --000000000000caf9840577c960e2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


= El mar., 9 oct. 2018 5:18, <f= lorian.csdt@gmail.com> escribi=C3=B3:
Le mardi 9 octobre 2018 04:24:53 UTC+2, Daniel G= utson a =C3=A9crit=C2=A0:


El lun.,= 8 oct. 2018 21:38, <mutant....@gmail.co= m> escribi=C3=B3:
That could be easily broken if someone replaced memset() with= another super_memset() function or similar which did more than one write. = How would the compiler know which write inside of the memset() function it = has to keep? Would it only work for memset and assignments? I don't lik= e the idea of an attribute that only works for memset() but not other funct= ions.

That's why I'm struggling to explain that this attribu= te is statement-wise rather than for annotating function *calls* only
=

Your very first example is not suite= d for an attribute on a statement, but for an attribute on the object itsel= f because you don't know (and will never know) where the object is (in = register? in memory? both?) and on which location the last assignment is do= ne.
Even if you could force the assignment both in register and i= n memory, are you sure the assignment in register has overridden the right = register?

Are you saying that the object may undergo internal co= pies for optimization purposes (e.g. if it is in a register it may be copie= d to other registers as a temporal)? It could also be arithmetically operat= ed in other registers which would still turn it recoverable by applying the= reverse operation.
Hm. Is that what you are saying?=

So enfo= rcing that the last assignment is done gives you almost nothing in that cas= e (That's why I proposed the [[undead]] attribute, but alternatives are= fine).

However, for other purposes I think it'= ;s fine (the memset example on heap memory) and here I completely agree tha= t an attribute on the statement is the right way to do (I just disagree on = the name of of the attribute because I find it misleading).
I als= o want to mention here, that it is already possible to do it with inline as= m (not standard).

--
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-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-propo= sals/e7edc1e3-a9b3-421c-a72f-623d6c34b104%40isocpp.org.

--
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 h= ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFdMc-0-p7rOo3= MYrfa%2Bx_zc21h58fZb_Qt5a1g6ocasCqyJXw%40mail.gmail.com.
--000000000000caf9840577c960e2-- .