From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-00069f02.pphosted.com (mx0a-00069f02.pphosted.com [205.220.165.32]) by sourceware.org (Postfix) with ESMTPS id A65E5398A495 for ; Wed, 14 Jul 2021 19:12:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A65E5398A495 Received: from pps.filterd (m0246627.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 16EJBg5j008606 for ; Wed, 14 Jul 2021 19:12:47 GMT Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by mx0b-00069f02.pphosted.com with ESMTP id 39sbtuk6et-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Wed, 14 Jul 2021 19:12:47 +0000 Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1]) by aserp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 16EJAlR2045573 for ; Wed, 14 Jul 2021 19:12:46 GMT Received: from nam04-bn8-obe.outbound.protection.outlook.com (mail-bn8nam08lp2048.outbound.protection.outlook.com [104.47.74.48]) by aserp3020.oracle.com with ESMTP id 39q3cfxt81-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Wed, 14 Jul 2021 19:12:46 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AUUGyFRem/xcMqyC5zU8WNt22snSXA9xKLelqYNbRC+8JtsKfLxgt1+WqHujqfemg+bN64w7uSrLq6JRFGQxWDFhQeZ/y7+Yk07EvGRXZcbagocppX+F/S4/Fkda1o1X2catA4XGJcKd9gRmvUzRgWMYQ4TnAhzPRcWHWmw9mxtEs5ARKb9FYBUymK4UAZNf5IKdk2hP7dPnWbG2TaH2mLSZZebjihEX5f8X3yh2lVD+bSS+1Ovbn4AEEUbeqcaiFrXUi1o6TBvizXMilBbI1+FmY/JlRmNxjTWLPvenkEtaHkJIJz+5AF629U+iyZaCrsKS2Q4v2aNMjy0xjijXKg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mEIquVNdPzw6evgSOCCeqspDtBcnEmnauRLMERJUt/Y=; b=JgnwME14xX4tHdduFaOzeLQ2j9biLMYk3jeegk77wC5bKVBUQN+YpUbq1LFHs2IxxjaieZHDQdfrOI4hCODYjGly8gqNqh3epDhHgbjFlrnpP37S8ee3XtJZkjkM0IIrklEaZ6CBpf2tYb+B92CO+JOHwGiRgQLymSnSjT3jy1jdzYj+Zp4oK6lC1feJbAvsouCzeOqyHb5fOHWBD3zblvOBC1XZ5eWKEeH0LuKgiaaciZrUdnpR9ByUIPFSnlAUgHk3kuAfG2XFu28wr8VmQ4xm9r71esxSWZFlyi2vJwKgKtx818Em/pxaD6VGltBxHJW5ALH3pa2aSMf+j+K0pg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com; dkim=pass header.d=oracle.com; arc=none Received: from BYAPR10MB3208.namprd10.prod.outlook.com (2603:10b6:a03:159::10) by SJ0PR10MB4704.namprd10.prod.outlook.com (2603:10b6:a03:2db::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4331.21; Wed, 14 Jul 2021 19:12:43 +0000 Received: from BYAPR10MB3208.namprd10.prod.outlook.com ([fe80::45c2:73e5:65dd:97d2]) by BYAPR10MB3208.namprd10.prod.outlook.com ([fe80::45c2:73e5:65dd:97d2%6]) with mapi id 15.20.4308.027; Wed, 14 Jul 2021 19:12:43 +0000 Subject: Re: FYI/RFC: strub: machine-independent stack scrubbing To: gcc@gcc.gnu.org References: From: Patrick McGehearty Message-ID: <86a204b3-707b-3f5e-d185-0b083af7e1ed@oracle.com> Date: Wed, 14 Jul 2021 14:12:40 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-ClientProxiedBy: SA0PR11CA0107.namprd11.prod.outlook.com (2603:10b6:806:d1::22) To BYAPR10MB3208.namprd10.prod.outlook.com (2603:10b6:a03:159::10) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.151] (47.184.4.28) by SA0PR11CA0107.namprd11.prod.outlook.com (2603:10b6:806:d1::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4331.21 via Frontend Transport; Wed, 14 Jul 2021 19:12:42 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 78b9697e-06ee-4c66-f800-08d946fb5b05 X-MS-TrafficTypeDiagnostic: SJ0PR10MB4704: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: sva0JdVssvQ83K+pdfoN/ial81vruvHIqTo3YZxnPdNVXyrOWx9K2EwMRWyl2VgWKaBKqFHR1k2J4sBQxi7VmJPFZODF9otW+454CHS/eBUkLxRCdrb+yfLsYUfMQGHgTXxHFZhO76Z/xUuMBka6LpjSimWxo34lx/aFJ0QqRDgbKl5A8G8j2KGErbFmGoxWbF2QL5zfX7CQ16AzDtlzPKzk+wG+AAUc7/3asrA9/0kKnNBCk79xr44zn8iOF3ug7y40H1zcCZMkXLW+/kwj41VPiaNxzplpwk2l1ZUcqGLrUoSyp5b4I3fDb/qxlal5J2CukDEcTjJbuwL/sRK8vBsrxFRvhGbI3q4olCWMp0BocMs99n+AGpFw/jmmBHXbMFa6jyRfl9wzfoRz8HQJqqdlrHnGK2yfHBBwn0Vh+d275BOk6rtcTcVH7Wxv7iPH5zjpr2GlAPtxVuLn/FYHkT3WWM/378l4g6/ycf5F/YBgLqNeGqUh+mRfTsTkZo1FgRESmxjjgGXjNseM3Efn9Ke0hC2NEYJ0kXZUgcNy2UXyAQMK530srRDkOO10Q/vM+LZpzGAvV/ZdLAgwvAVe0vap5dr9XhEvIkQH7zF9GksinI6gP4z8wa8uxKHBIAkkhFgbTz2olXIqgP/VtpmgVqdqzxyOcXId4yDug/2trShAk9PEfDra1PePmU8UgohS4a7MvqU2p+uRAxJSZUxWMlU1MGsNH62rhNyenqd9LOLxGvOb0cmbrthQ/RAZm91is7tXpzquIAUjRrBqpaybVA== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR10MB3208.namprd10.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(366004)(396003)(136003)(376002)(346002)(66946007)(26005)(6916009)(8936002)(36756003)(5660300002)(31686004)(83380400001)(8676002)(31696002)(186003)(66476007)(478600001)(316002)(86362001)(52116002)(45080400002)(16576012)(38350700002)(956004)(6486002)(66556008)(53546011)(38100700002)(2906002)(2616005)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?RVZ4UjVwZ2Noc3d3NjFmWW1tY29yOSswSlFnL3ZsUWdIU0RhTmM0bWtucnRw?= =?utf-8?B?ZWpBdnByNU9OM2lxaExqUjJrZlJxRzJOc3lsbTNGU3dkcm0wemJUanMxNkll?= =?utf-8?B?WGt3bG03dk1EUnIyaW5Qckc1OTFTZFRadHp6UDNwMURocGhPbFFrS0VQRnJ4?= =?utf-8?B?REEwbGUvTHkyNmR6ZGdsSFRFOXdDWG1xMmpKdWM1OW1YWXNBcUNtc0ZseUtY?= =?utf-8?B?OWZTOEZ4bVJ6ckNwaDg2YTRxZDJQRjZrUUJTdTR3YWxHb2tkbU54TVZwelVV?= =?utf-8?B?L0tVdnB0cnhqblcrc1pEUGdUbjcwNjBwZ0p1S0lVaWVFTC8xQlZmQkJmRkl6?= =?utf-8?B?eHJPaFVrMHFJcVNGNS95RGNEWWd2djJHLzdDSkFrbmFRTzR3bUc4R0RlYm54?= =?utf-8?B?ckpId05NN0M5eDJFaGhKNTBXNVdrZGxoYms5RHZoU0hjWlNTOVRKeklhMjFP?= =?utf-8?B?c1U3VDl0ZW5QNTgzRTR3SlhDY1hmbDBCYlVvQkVVNUpsVitOWTFYUzZpTWZo?= =?utf-8?B?ckxLTVo2QkJWbWZ1dkZBa2U0QWZUVjBzOXVVbGF2S25aeDVGRTNKR09BQnpJ?= =?utf-8?B?bzNHS0Q1QlVISVJaSU4yZFFhVHpndzdSSlRJTTZrWXQzV20yWEdxSXlmVzM1?= =?utf-8?B?ZGtuOGppSFllU3dwQlRtTVhFQ2VFVzNNWjBkanUzYUxxYmcwMG1kMzZuQSsy?= =?utf-8?B?bWtNYVBKZUQyOUtudjVvWW9FVGFVWVVQaUFwckRSdFB0MS8yVi9VTXY0ZFlk?= =?utf-8?B?T25KNFJxT1ZaU204WWQrdmRLUS9HSTRuZER3UzRZQ0xEang1SHg2ZGVubFdE?= =?utf-8?B?enRUNFEvMU9YOFRwNG9ONXplTE10V0dLeUNHWFkyMWhGQ24yNGpycVlEQ21F?= =?utf-8?B?YXQ4aWlzVkNKa3VQNmowZXRMdFFHbVpCbXhMc0pnc2hteDNKR1dmcWdyQkkx?= =?utf-8?B?dDRkc1lwZ1hzOXUvWElET2RnSzJaUzZFZVJBL1o1Uk5MUExWNlpMSnI5bE5P?= =?utf-8?B?MjhZUnlIRnNScmltb0xVWGZLaG5ZbnFxQWMwRkRzbGJsMFFSNXkwT3JOU2tP?= =?utf-8?B?TEIvOHlMN1NlZmlKdWhDaFVlRGppVlc0M3pyQVlpZXJFSHB4eis5TVljR3di?= =?utf-8?B?bjhsazR1Zk5WcXBHZmlvVlBNejYzUUhydDA4bldPRmMxRUdqMzdvYjA5Rjhu?= =?utf-8?B?SU9jak1aRDdwaTAvYXQwRlcvSEdKazUxSHZiVG01VTJsenVBRmdGRHZZay9O?= =?utf-8?B?T2xtRWNXUHB4TGR4b2tCVkJyNExEbTFBUlBPdk1xaGFIcDg2MVVETTBMcDNO?= =?utf-8?B?RGFGTDd3bnpCaFUxcFpmWkp2MmdEUW9CaWFSYXpxaWh3M3FrNnRPR2xzQmRT?= =?utf-8?B?V3hEY1ZNY3ptV0IvMTYyMytyT0Z4azZQT2JTZStId3h3ckRYV3A4elJVaFp2?= =?utf-8?B?UFlXdHk5SWpoM2JVVkY0ZWl1TWJKUjU5bjI4VzZoZjkwQjc5M0JmQXp3V250?= =?utf-8?B?VWlmaWZjMlBURm44VndGUDFWbk5idURpNDJIblo0OWV4Qml5R0VDWmo1YUFw?= =?utf-8?B?dFJZZE1oeE9tQUNPb2llZmNma05PVlNkQThtMUxJTk5VZDZSam5TY0pDWmNh?= =?utf-8?B?cDBPVEdPTnMzTUNhenBwdkRWZW9HcEJhTkNmN1JtbWpqa2xyY0R3aXNnK0py?= =?utf-8?B?QlJ0TDNNcWNxMXpybGJ2S2xadmk0MHBFS3VUNm5MUmR6NXlQQlZaQ2thRnhE?= =?utf-8?Q?NM45rmD5Axx8IrITCzjWUUgEDoZiC/3Wrryewnn?= X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: 78b9697e-06ee-4c66-f800-08d946fb5b05 X-MS-Exchange-CrossTenant-AuthSource: BYAPR10MB3208.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Jul 2021 19:12:42.9598 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: zZ25qv+dto6zuejvRHBezd0Yd1YZnbw0AIujz7c0AxWorUqXaPe94SF9VDFFLk8gn/WDuMD0oPG/elnx+9hQEHV4FzWo7a7Quyw2L07ba/U= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR10MB4704 X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=10045 signatures=668682 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 malwarescore=0 mlxscore=0 suspectscore=0 phishscore=0 adultscore=0 mlxlogscore=999 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2107140114 X-Proofpoint-GUID: K1HlMnv1uDNuNzT0J-CZLoZlDesv7YpF X-Proofpoint-ORIG-GUID: K1HlMnv1uDNuNzT0J-CZLoZlDesv7YpF X-Spam-Status: No, score=-5.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, MSGID_FROM_MTA_HEADER, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2021 19:12:50 -0000 I don't have any special expertise in this matter, but the possibility occurs to me that if the caller is an improperly vetted runtime linked-in agent such as a device driver, then the stack scrubbing might accidently or intentionally be omitted, reopening the security hole that stack scrubbing is intended to close. Having the scrubbing occur in the calle means the callee controls what information is returned, making it responsible for its own security. Someone with a deeper understanding of the security reasons for stack scrubbing may know whether my concern has any basis. - Patrick McGehearty On 7/14/2021 12:28 AM, Alexandre Oliva wrote: > I've been working on an implementation of stack scrubbing, strub for > short. It's quite different from the one that Embecosm folks presented > at the Cauldron, in that this one aims to be machine-independent. > Instead of machine-specific tweaking of epilogue logic to zero out a > function's own stack frame, this design performs scrubbing at callers, > passing to strubbed functions a watermark pointer, that they update as > they move the stack pointer. The caller performs the stack cleaning up > as a "finally" block after the call. > > - functions explicitly marked for strubbing, or internal-to-a-unit > functions that use variables marked as requiring strubbing, just have > their signature modified to add the watermark pointer, and they update > the watermark at the end of the prologue and after alloca calls. > > - for functions that require strubbing (say, for using variables that > require strubbing) but whose interface cannot be modified, the body is > split into a clone, and the function is turned into a wrapper that calls > the clone with its modified calling conventions, and then performs the > strubbing. Variable argument lists and of builtin apply args are passed > as extra arguments to the wrapped function, so that these features are > not obstacles to strubbing. Large (> 4 words) arguments that are not > gimple registers are passed by reference from the wrapper to the wrapped > clone, to avoid duplicate copying. > > This is currently prototyped with an implementation that enables > strubbing for nearly every function. Some exceptions are always_inline > functions, and externally-visible functions with attributes that prevent > cloning/splitting. > > Inlining strubbed functions into non-strubbed ones is not allowed (this > would reverse the wrapping); I'm yet to figure out how to enable > inlining of a wrapped body when the wrapper gets inlined into a strubbed > function. Furthermore, I'm yet to implement logic to prevent strubbed > functions from calling non-strubbed functions. > > The prototype bootstraps on x86_64-linux-gnu, and builds some working > cross toolchains. I expect to contribute it not long after it's > completed. For now, I look forward to feedback on any potentially > objectionable implementation details that I've described, and I welcome > advice on some issues described below. > > > I've added a builtin that returns the stack address, and 3 new entry > points in libgcc, each one also associated with a builtin: one to be > called before a strubbed function, to initialize the watermark to be > passed to it, one to update the watermark, and one to clean the stack up > to the watermark. I'm considering making them independently inlineable, > inlining none of them at -O0, the first one at -O[1gs], the second one > at -O2, and all of them at -O3. > > Functions and variables with strubbing functionality are to be marked > with an attribute, and I'm leaning towards naming it "strub". For > functions, I intend the attribute to take a parameter, to select between > the two strubbing modes, or to disable strubbing, whether enabling or > preventing calls from strubbing functions. Internally, I'm using a > numeric encoding for this attribute parameter, but I'm considering using > such mnemonic terms as "at_calls", "internal", "callable", and > "disabled". WDYT? > > I'm also considering the possibility of adding yet another scrubbing > mode, that would select optional machine-dependent epilogue logic, as > implemented by Embecosm. That will depend on schedule and on whether > this possibility is found to be useful. Extending it to catch > exceptions and perform strubbing of the propagating frame seems more > challenging than the caller-based strubbing I've implemented, with > exception support. I could use feedback on the usefulness of this > strubbing mode (and on any issues with the others :-) > > > The prototype uses modified copies of create_wrapper and expand_thunk > for the wrapping. I find the body copying and dropping wasteful, > constraining, and, in some cases, bug-inducing (taking address of labels > comes to mind). I wonder if it would be acceptable to introduce > wrapping logic to short-circuit the process, moving the body instead of > copying it, and introducing hooks to grant callers better control over > argument passing. The approaches to va_list and apply_args, and to > passing some arguments by reference could presumably be useful to other > future wrapping transformations. > > It would be nice if the arguments turned into by-reference were NOT > detached from their abstract origin, but rather were supported as a new > IPA_PARAM_OP_ kind. Do these sound like worth pursuing to make these > possibilities available to others? > > > Thanks in advance for feedback and advice, >