From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from userp2130.oracle.com (userp2130.oracle.com [156.151.31.86]) by sourceware.org (Postfix) with ESMTPS id 2A486385E83A for ; Fri, 7 Aug 2020 16:15:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 2A486385E83A Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 077GBxwR027558; Fri, 7 Aug 2020 16:15:35 GMT Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by userp2130.oracle.com with ESMTP id 32r6gx1cwk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 07 Aug 2020 16:15:35 +0000 Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1]) by aserp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 077G9IZS192069; Fri, 7 Aug 2020 16:15:34 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserp3030.oracle.com with ESMTP id 32p5gxe6e4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 07 Aug 2020 16:15:34 +0000 Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 077GFWkO007086; Fri, 7 Aug 2020 16:15:33 GMT Received: from dhcp-10-154-151-117.vpn.oracle.com (/10.154.151.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 07 Aug 2020 09:15:32 -0700 From: Qing Zhao Message-Id: Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) Subject: Re: PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all] Date: Fri, 7 Aug 2020 11:15:31 -0500 In-Reply-To: Cc: Kees Cook , "H.J. Lu" , Uros Bizjak , Jakub Jelinek , GCC Patches , "Rodriguez Bahena, Victor" To: Richard Biener References: <9B287E7F-5D0F-4BE2-8276-2F6ADFBCF3F4@suse.de> <202008061337.025137A39@keescook> X-Mailer: Apple Mail (2.3445.104.15) X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9706 signatures=668679 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 mlxscore=0 bulkscore=0 phishscore=0 spamscore=0 adultscore=0 suspectscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2008070112 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9706 signatures=668679 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 bulkscore=0 spamscore=0 impostorscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 priorityscore=1501 phishscore=0 clxscore=1015 suspectscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2008070112 X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, HTML_MESSAGE, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_PASS, TXREP, UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2020 16:15:44 -0000 > On Aug 7, 2020, at 1:21 AM, Richard Biener wrote: >=20 > On Thu, 6 Aug 2020, Kees Cook wrote: >=20 >> On Thu, Aug 06, 2020 at 10:37:43AM +0200, Richard Biener wrote: >>> OK, so -fzero-call-used-regs is a ROP mitigation technique. To me >>> it sounded more like a mitigation against information leaks which >>> then would be highly incomplete w/o spill slot clearing. Like >>> we had that discussion on secure erase of memory that should not >>> be DSEd. >>=20 >> I've viewed stack erasure as separate from register clearing. The >> "when" of stack erasure tends to define which things are being = defended >> against. If the stack is being erased on function entry, you're = defending >> against all the various "uninitialized" variable attacks (which can = be >> info exposures, flow control redirection, etc). If it's on function = exit, >> this is more aimed at avoiding stale data and minimizing what's = available >> during an attack (and it also provides similar "uninit" defenses, = just >> in a different way). And FWIW, past benchmarks on this appear to = indicate >> erase-on-entry is more cache-friendly. >=20 > So I originally thought this was about leaking security sensitive data > to callers and thus we want to define API entries to not leak any > data from callees other than via the ABI defined return values or > global memory the callee chooses to populate. Clearing registers > not involved in returning data is one part but then contents of such > registers could also reside in spill slots which means you have to > clear those as well. And yes, even local automatic variables of the > callee fall into the category and thus 'stack-erasure' would be > required. To appropriately have such a "security boundary" at > function return you _do_ have to do the clearing at function return > though. In the following slides of The Secure Project and GCC: https://gmarkall.files.wordpress.com/2018/09/secure_and_gcc.pdf = It was mentioned that the the stack erase patch For GCC would be = submitted to gcc upstream soon (in 2018). I am wondering whether that patch has been submitted and discussed = already? Qing >=20 > But it's a completely different topic and it seems the patch was > not intended to help the folks that also ask for "secure"_memset > the compiler isn't supposed to optimize away as dead. >=20 > Richard.