From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 29A93C27C4F for ; Tue, 11 Jun 2024 02:50:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9813E6B009B; Mon, 10 Jun 2024 22:50:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 930286B009C; Mon, 10 Jun 2024 22:50:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7A9836B009D; Mon, 10 Jun 2024 22:50:18 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 56D326B009B for ; Mon, 10 Jun 2024 22:50:18 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 015DB8080D for ; Tue, 11 Jun 2024 02:50:17 +0000 (UTC) X-FDA: 82217078916.11.B91EFC1 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2079.outbound.protection.outlook.com [40.107.223.79]) by imf21.hostedemail.com (Postfix) with ESMTP id 107CF1C0009 for ; Tue, 11 Jun 2024 02:50:13 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=Nvidia.com header.s=selector2 header.b=FHtAzxXN; dmarc=pass (policy=reject) header.from=nvidia.com; spf=pass (imf21.hostedemail.com: domain of apopple@nvidia.com designates 40.107.223.79 as permitted sender) smtp.mailfrom=apopple@nvidia.com; arc=pass ("microsoft.com:s=arcselector9901:i=1") ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1718074214; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=1fDNWe8ow6zb+WIaACfYPSmsN/vV2tZt3UnZeg0bXFE=; b=4DPv/yKvnGBgQgCS2AdQ74ixn4EtK5/n7Df+uR3vhuB4ncYkuQDQtUmq+rKxgWNZ9BqfNs pl/l8VMNO1HVvh5jj1OBA9DbxbQ8upASauUg+ZBfY5hsTVIK54KjW9n0lyixWx/dIKzJA9 fDE9C+n0QPXlS+q03lNSRdOP2TKGPdo= ARC-Authentication-Results: i=2; imf21.hostedemail.com; dkim=pass header.d=Nvidia.com header.s=selector2 header.b=FHtAzxXN; dmarc=pass (policy=reject) header.from=nvidia.com; spf=pass (imf21.hostedemail.com: domain of apopple@nvidia.com designates 40.107.223.79 as permitted sender) smtp.mailfrom=apopple@nvidia.com; arc=pass ("microsoft.com:s=arcselector9901:i=1") ARC-Seal: i=2; s=arc-20220608; d=hostedemail.com; t=1718074214; a=rsa-sha256; cv=pass; b=e98CKaEdfUYe4jmPyILtsNx6KU8WmObbDbmJuFGGe55FYkw3BgqHW9YPWLlMWqzu0h9uV3 LKLDbBSUjOSbJyae2Crkso2k4XCCJjCEq0A1bcx8CEl1y3G+njONTA9VNaMmRBSmV547Nu bbpqhmqFwbsdK4tURNulYrlZUjhcYeU= ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NSXvFErQkL2MnOAtw2+7SOv5CXw7r/bzyIJ74jBiWHR7jS3DSrJc3rUPB8BMXsYmwMJ5K9N1JHCjcSgumX6P1lKAmbg806nqFD6Nu516QwZEQ/GirjchEf9+lbvdfcwK+wUwduHrG7dJfvk1DIUZhcmvFk4QV/OwM1rStKsgR2f3RfKOyQlPyW8kCaVxe50zZ2gqNz0JvZoD24+urwwBt+DMXQI8sZyOnzoq0wbUMlT+bpMhebH8kwjWhg73u+ifvxXVAs6Hm7kf7XxkA8HP/nie4fDOxEV5TWstdMgJIJdr0j24ad7GLjPLBplOSRR+b8g1w/Pl2X2Q6aDpON+NVg== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=1fDNWe8ow6zb+WIaACfYPSmsN/vV2tZt3UnZeg0bXFE=; b=DnxWETyJ4UHpNGMAuP0Kdxb2Aa8Tmd7qBhBeB8f24B9G4XPNmFaxiT4Mh45ZjAdCTT4WKRQ+QvHX7MbAxBFrlN+ylnudX4ccnSKXX6JEO0O8MctSI+PV+5jwSeRFNUldKMulCoMzginIV20ZGRdkcelM0qQtczlIDg/QwPoFX+IUiuWAfzcIWBLL9QF6GxL28rlHrW4NrSihJZfI7GMdA7Y3BR705EpjLt0iXnNNe0P4VuXr7Fl4CXQp8cm6J9GMmxKmNy2H2EgfvWNwphNiONTNoXCYiXbITWWAkzRPrUKABHJY5XSqhtPmOm451LbQQB1mEhbnC6hkEt5V8/SaJg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nvidia.com; dmarc=pass action=none header.from=nvidia.com; dkim=pass header.d=nvidia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1fDNWe8ow6zb+WIaACfYPSmsN/vV2tZt3UnZeg0bXFE=; b=FHtAzxXNInlURUEMq6u23nsSzmjED3URoupbuBfyYRbUIN1T0WIWfa7FXUNSzPQ+O+DfL81VDeoSxcYhIOY+N+KAc+dGNFa31SgdyK1vNW17LQcyYw1cYlEcSuHn3QoFxkMwOsRFteNK5Xxs5i/9jUbOfOqWqVIp3dPElM4eox4VL8gSX9v9CWm3u2tg4nA1QdubxNCtW6MtUtl4QThkRmr5MKaYEv98BjCd8GBImq2O73F7tUpUjzMBc3CRptcANI1YyXfEmQ1o1CSNLP3zJCRtrbIYjDTVUU4/g9Rl9aWpUhKyR+BlpxdAsUEAlMPPxi3KSSkTPhHiieLEqdEv6w== Received: from DS0PR12MB7726.namprd12.prod.outlook.com (2603:10b6:8:130::6) by CH2PR12MB4311.namprd12.prod.outlook.com (2603:10b6:610:a8::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7633.36; Tue, 11 Jun 2024 02:50:07 +0000 Received: from DS0PR12MB7726.namprd12.prod.outlook.com ([fe80::953f:2f80:90c5:67fe]) by DS0PR12MB7726.namprd12.prod.outlook.com ([fe80::953f:2f80:90c5:67fe%6]) with mapi id 15.20.7633.036; Tue, 11 Jun 2024 02:50:07 +0000 References: <2024061055-shone-clean-3d0d@gregkh> User-agent: mu4e 1.10.8; emacs 29.1 From: Alistair Popple To: =?utf-8?B?wq3rhbjsi5ztmIQ=?= / =?utf-8?B?7ZWZ7IOd?= / =?utf-8?B?7KCE?= =?utf-8?B?6riwwrfsoJXrs7Tqs7XtlZk=?= Cc: Greg KH , "akpm@linux-foundation.org" , "security@kernel.org" , "linux-mm@kvack.org" Subject: Re: [Linux bug report] A bug breaking device drivers' fault isolation guarantees Date: Tue, 11 Jun 2024 12:35:48 +1000 In-reply-to: Message-ID: <87frtkuraf.fsf@nvdebian.thelocal> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: SYBPR01CA0192.ausprd01.prod.outlook.com (2603:10c6:10:52::36) To DS0PR12MB7726.namprd12.prod.outlook.com (2603:10b6:8:130::6) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS0PR12MB7726:EE_|CH2PR12MB4311:EE_ X-MS-Office365-Filtering-Correlation-Id: f115a7ba-3a9d-4b28-a01d-08dc89c133c2 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230031|376005|1800799015|366007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?TmxQb3M0OC93bkMwd242WW16Y29UdktTbnAxcEtJNDhGWlp2NFc4ZXdaY3Ax?= =?utf-8?B?MUJvUnZRMW5sT0tpaC91MS94S2JqaGFaM05peCtGOG1hV092VUdyZXZqZXda?= =?utf-8?B?eFFJTXpzbmpYaXd5VGZheGhMQk1rM0FXeGdVaVJCUnpERGpoUkxuQjVUVjAw?= =?utf-8?B?TCs5dGZLd0V3QXZRbHQrd21oM2g4RW5IN3JkTzd3Qk11ZVo3QmdCdDBpcUJ0?= =?utf-8?B?M1RIZWYxUUtEMWkrZHc0OUVIUDNZYXRjYmxUaTl1ZzZTTW5Jdm1MNC92aWQ0?= =?utf-8?B?clVLYmtRRm9TZ05VM2ZtcHphNGM5OURVTHduL2FVRTZORlZNWGVkRVBiVjB1?= =?utf-8?B?QVd5SlkvNFBRQVh6UEovYkR1OGZuOWRzR1FZajhFM3UwTVkzRFEvaDE1cDEz?= =?utf-8?B?aFhTZGlSdy84MUVYdFozTTRDYUVrQWdYYk1yK1RyTklQYitNUzF4NHlmY3BG?= =?utf-8?B?Wjk3S21iZXZpaFBKMy9SK3J5ZFc3eFIrT2hqSDdOSUY3SzJJY05GYjJ2Rnlv?= =?utf-8?B?ZHVnWSsyaEZld2srd2RDU3JJUjNDdkM0WXkvV2hqSW5zbVpnMWJjVG9WTitw?= =?utf-8?B?b2dUQS83TXNsNGtDTEVKWXMrT1gxWXZZWDREUUFsYTFzSkloY1AyejhVekNi?= =?utf-8?B?aFJRZ0pEc3ZTdC8wb1VZSDBlQUo3VDFvd2dLbGdLZXhFcURmU2V5ZEY1RVVl?= =?utf-8?B?bERFTDBwWWpnN2x0Qm9GUmxGejhBSGpIbHFzMlVDRkhYdjV2TFdqeXAzS3BC?= =?utf-8?B?THZnanBGNnd1NUtDY1Rjc21sanVPNlRhOFZmdGp4NzBVTU52Z0p3ZW5iQU13?= =?utf-8?B?OVpuTXg3eG44anRmeGFYaUNFYW53aUxzQUp5bzZHZ2ZXT2s1YUEzUlJYVUFo?= =?utf-8?B?dDFvL2JSMG11dEVia2pjaU1yTnQwMmhlYlBkcm9FZGtYeENxZnhUT29GVWNt?= =?utf-8?B?eG5ORzB0YW44ZDExaW1KSG5JVVYzT0p3L21tQjVNaHRwcnRmakRpZWozZjVo?= =?utf-8?B?ampDcHpIQ1NjQ1JlUDMydlhJSHBLQnV1VGl4c0pJalJmSXZCMUdDUm9haHJC?= =?utf-8?B?N0xvQ240bm5FMk1pdzl2OEpzUElzYmdNZHIwRDc4cXpxbGRZcFVKSWlLcm1Y?= =?utf-8?B?R2VHVWVROFNlMUZKaGFQWHpva0lRUWViUDJZWTJNRTVIOTByMkNHRHEvZnFy?= =?utf-8?B?N084Y0NGYVIyWDlib3I1MUw0dldQdkVBRng2bkJSVkRObGFUOHhsMkcxTk4v?= =?utf-8?B?Y0ZFeHpOSFhhbDlLK3FEVC9ZQU5GbU42UldoNEpMZW5JZWFiRlBJaGRYbG0x?= =?utf-8?B?Wkk5Y1QzNmNhOWlsdERpNGowSzhnMHM4MmI3UlZFSEFNdXJCYzhpcmIyREJn?= =?utf-8?B?c05paHFRRlNEYTAvNGVDczkrakN0WU12T1dieWc5bERNU1NNdXIxVVdTaHNm?= =?utf-8?B?KzQ4bjhMeXNvYXE1N2JuTExwMlZicFBhOU54SEVpOW9PSmIyOG1JSFJURlNX?= =?utf-8?B?TVhEOFovUWFRNy9TdlhJb3VaNHluZXBiTmhteUp3Nml1T04rVVZKaExlbm53?= =?utf-8?B?RE9ZVGk3WWEzdVgzWnhyZ3BDYy9odkpqa2FyUExQN3RZWkZyZDZ3czBIQ2dP?= =?utf-8?B?b2szMzM5ZXpVTDRXQmhKU3lNRVVyQVZXN3RpL3o4WVU0Q1BPRTU5c2YvWUky?= =?utf-8?B?SVFLNUtHOE1iTDJzOFEvV25lUVBBdXN1ZjlCMUQwOVpBcXZzRUNWYzFoT1Q3?= =?utf-8?Q?eUOPLZD8BYNx2wIf8dPptO8PNI2FkbH8JdPJD6a?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DS0PR12MB7726.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(376005)(1800799015)(366007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?L05BUmxMcEtwWE41eC9pMnYzMHd3RjVhZEJrcDkyRTRuN25WcWlmckxPajR2?= =?utf-8?B?Kzd0czUwVCtScmtvUUFWaUZLUG52MzBiK3RhMHpCVjV2NitLeEovWm05WDQx?= =?utf-8?B?U3pHRlArblVTSEVjSXdVeEw1SFNzMXFkRDAvTEkvMmxhK3FHR01nMXM4MnJ2?= =?utf-8?B?Sm8xN2lVNURlT3BwZzdKS0NYczJkdkduaXZTRTdNZkdqNjZpZWZSN292cmVS?= =?utf-8?B?cnVyR1hFNm95djB3MzdvUUI4UWZJbTZHTHNhUTR3WnVic25XT2tyL2s0YWVL?= =?utf-8?B?UmJ1WWlzQ04xcXVCU1FhVDlHY0NTdVFqWnFaQUg3MGRVUVprcUVwSmtFTVhp?= =?utf-8?B?OXlaS3dOQ3VRQ2JZdU5RbVdJam10UXlSUy9ySXRaV2NxdGNSWEk2cWVzMzFL?= =?utf-8?B?anY1WUwzUnZYQVpJQ05mYTlHMzVvL29hRmhkUDVXZUR0dDM2L1EyUWIwelFr?= =?utf-8?B?RmhUU3pScThkaVp5cTlFM3Y0U0dTMlV3RXBNNFc2MUhaRUR3T3JGUXg0STJB?= =?utf-8?B?N0dsK0hsK0JNUkRXdjRHN05UcmZFcys2bWFveHljdm96UUJUVUc5R3U4NjRn?= =?utf-8?B?RDBZK0VYSGI1bW9tMmZsQnlwZlo5OTZ6WXJ6clg4RG5zR3VlWVdkaldGK0pE?= =?utf-8?B?T2VTOC9WWW9FdGJCZ01acFQ4OWJ0MTA5OUhXemVpbHR1VnB0RHZSd3JRdjZr?= =?utf-8?B?eStPcWVza2x4L0hVbkhDN3lSK3dZMlE4TVY0eXpUU09URGxiYUpYNHFUemRw?= =?utf-8?B?RGdQWWI4TmVVZWZyMnN0UUNiK3RtL1luUmNCbVFzUGo3aDVHOHFlTDRXeWo4?= =?utf-8?B?K3BvY3hUd3RrSGUrMW5qS0NLZ3NrQ0lrVzBWSDQwUTk0VG1WWVd4SjVIVkww?= =?utf-8?B?Y3pQQjdrdk5DSHFZcmc1cGVkdjlRWmh2d3VrSHN1NXdvclF1bXJoalFkT3pt?= =?utf-8?B?S2tIM2dJUE43V0xVZ2J5QXRLd0drSmxxTmYycVc3QmwrQWQ5RmRqaitDdHk3?= =?utf-8?B?am1XdFFHYkdYZnF3SWdpdkJtSkFtc0xtY3VpQWF0WXFzR1VJQWZyRDVIeHov?= =?utf-8?B?YU0vRXhyN29QMmp4eEFXVmtMOExLbDFIdHdxdnAzajZaZGZiYmVwWUtDanAy?= =?utf-8?B?S3ZCamFVZ2E1elJZMUEyMUNTVUJQNXV6L3RINjBwMWNCTnBIZ1BZZCs4V2lE?= =?utf-8?B?WU52dHltaHp6bzFhTDQyVEJIeHV5ZXVxOHArZjFLOWhKeCs4aEYvc1Y5OVd5?= =?utf-8?B?UnQzNW5XaEdnYkxTbjM0ZG1NcW9jZDJtbmo2Rkx5R3V0eVA1elE1OEJ1VDFG?= =?utf-8?B?ZVFZcTYxT0Yzb2ttWFFCSVpWN0JnT3h3L2FjK21NcERsV1BHaVAvMmsrVE9R?= =?utf-8?B?R2lwclVjdjVFZVVvN2JlOFlYVk1JbDFVcE40ZHNITCtEc0dzSjJHajJJVG4v?= =?utf-8?B?bXNsS05ENW1MamNXSG0xQWt1cFVwQzVRTDB3TVpXVkZnNGVMVnVrNDY0cHRH?= =?utf-8?B?SUgwemRQOXk4bHk5c1hmRXltVFFuNTBkaWlTNjh1aFpyaDk1VE5LZkxsQ3Y2?= =?utf-8?B?d1Y2WUVXRWpGRVQvdVByejRreHREUVNrTHR3OXR2MzJ4VmRxY3JZQWQzR3JE?= =?utf-8?B?WTJCRUQxRFB5WHRSS3gzZUQ1dFpFVGlVL3dtNXhKS2t5MDBEYXk4YVhPdW81?= =?utf-8?B?ZElwTFFHUWh4eGVmMXU5REc2SHY2SStITHFUdW8wSGkwUGVZZTY0aUNEa1g0?= =?utf-8?B?bTJvdW9DUGZpMGZES1pCVkRwZkxYZ0NyRXVCUVlrNWZRZ1lvSnpuL0FSZFhp?= =?utf-8?B?bjJCekJNRzhGeDFOMVlkREk2T2QvaVdsMWpXS2RBNDhvOHRjMnJxNThzWE8v?= =?utf-8?B?dmRPbjhyOXVoSUY3Nlo0SFM0TzNDZVJQdFM3TEhLOHRnV2l5VzM3Tk5zVUls?= =?utf-8?B?dWlvektFUjYyRk9tRFJiSFhJRnRKanJ6SjdtNmlIbFYzd0QzYkJPYnFndWhS?= =?utf-8?B?alcyY2ZZSCtUR2lLZkVHOHBRUFRxYTc2a09oc0ZIK0J0Y0RpYU5BVTBpY1Jz?= =?utf-8?B?K0JBeTlydnNqZlRWbzg5S25GQjU2VFZxNjNhazhRSUgxRlY0YkNLR0FzK2xx?= =?utf-8?Q?sj6m2OwxWSCXAepeCLtGVLP7V?= X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-Network-Message-Id: f115a7ba-3a9d-4b28-a01d-08dc89c133c2 X-MS-Exchange-CrossTenant-AuthSource: DS0PR12MB7726.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Jun 2024 02:50:07.4709 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: FJsVvVTYCGRrA+jpYAiiOc08+rID2/NFjdiHvoVJEp7Ana8Ce/8ud7Bl21FyWN4Z9J7KwJH1c7DBKgrAnl72/g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR12MB4311 X-Rspamd-Queue-Id: 107CF1C0009 X-Rspamd-Server: rspam10 X-Rspam-User: X-Stat-Signature: gcdrygj63kpqsodq4rcauio48d4h5w3p X-HE-Tag: 1718074213-696910 X-HE-Meta: U2FsdGVkX1+jyqcTadyZ5vRzC1gNqfsYZet/JTib3szWVh0NHX76XNi7X7RIhbRoz8uxINlXTB9i2qQxyVrmqX0AXhMtUHp/JvjXZspaWEvdE7+gkMw0SrpUjS0I7dd4JY7VLpTSwkEQZOXED0NQJMUHSKGbHQTMu0hCcIwILDpgK2MIqQRm43ra5Bqsua4VTpurDZ1felrthaLqSf0NyN5QZOdXojqDcW8ei1QAi6vV4CrqdUdUGiFDUv+sAxv/a5ZP2Jrey2jMIqwr5T3T4dkGPwqafExHoYssnPVNTHzSuaYhuCPb6c36KZg5tEKAb3Fw3urj4S7u7vob4jsLRWhz8Mnv4g5OmOJgaKXJFRI3zG/8q6gdlK6ZLo4AbDN9hls/XTDwEM/CipngRQXHTE0mYicW20aDLOdc4RSSf+b71a3Nh3MhRLv5gU7MwsJ4A4ltK1AuUMF4PNyindMLy8FktYX2W7FGuhLFXxcoDhcoAGyRqp8LSoXeLJ5h1nfcUo/oebztvvTdIlde/DhT+BIzV4wO6zoAzxo/1Zwj+QR8Fa/z1+us+CWxQZThwO8GIjecEjo4eopfpSBctIbwufoHRi3YqPHBzHKWyynhtZW1LR6/DE1I6D63tJGVZqlawHwUKO9uvbTB/CHj0nTzwR0OTPeAEKtauAeAYoNBS9XxbVGv+6DAa6GUmoSYP76fXHB4EUWsfkmBc8qS6/bIrwdHEEG9kdPi8+OutiAREp0eAq4mc/4ULmnMWnMmELLKlkIxx1WpMJ80OQTE5fCUZqPbpnpjrPw2GD7dk4lQch6G87P3/5QNkqp36KYAQN9G33/5IcMNpkuL94WN6pryH+jjGmVe1ID8kwAvyxI+F+fpKM2klJvQQuSe/MpqEsJazuv8QEMPJ+0fJse4XLl8bi8pqZTDTC71L0qy7BIvh+H9Z4GMavq8LCoP+fPAuwRe87uNya//vsOrjmPxyy3 VF8naAaY xg2iDqH8EYL0prbH6TH8DVffZtk4b2IgEj6KYK+EHBBaIkrUEuwWNt2hdMlxdIhraxSbPzP7ijCkRFuWDhO4Nt37S0DFdJg2gBn9I/jOcqTSeLvDIcJyIfkI2p37rST+wtnNUHYzUE3Jn/z4w+HeS/DsyGudFTxoAMx32qXUbtFUZbE590+rLzfkrheKNBEcxxRaTE/eux4TmGn0x5jw1hkivrHSISUXyVbx4T9H21T9h2xhQU7eF0Rxtd33baFotf2bxZWpEOZIUI94Ig7oP+6VEcShgk2imKY6nkirSoIvx+j88jL1lHZY0xgXyEHbhlzV0Dd6t7y+F0IpOE/RVbxTLemjxPJcKF6JFwkK0TBntqrNZqbsCcBzJJRP4YPjZZLCEpSx4vwjBXfvMum73ONBA87x+Uy5mq1OC1LPVdx6JUZx0CNb6Ms0tfiAYCGh1laJFqWoY674Ivq/aO1zr4Sq0gg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: =C2=AD=EB=85=B8=EC=8B=9C=ED=98=84 / =ED=95=99=EC=83=9D / =EC=A0=84=EA=B8=B0= =C2=B7=EC=A0=95=EB=B3=B4=EA=B3=B5=ED=95=99=EB=B6=80 = writes: > It is an obvious linux kernel bug (wrong clearance of used data while err= or handling), and kernel drivers using this function can be affected. I wouldn't rule out the possiblity that this is a driver rather than kernel bug either. I will need to go look at the kernel code more closely but are you saying that after a driver calls a sequence of memremap_pages()/memunmap_pages() that any subsequent call to memremap_pages() will fail? Even if that were the case it shouldn't cause the below issue as the driver needs to deal with the failure. So I am having a bit of a hard time following some of the reasoning, comments below. > 1. Summary: Due to a bug in the Linux kernel, devices using the Linux ker= nel API cannot guarantee fault isolation between processes. > > 2. Full Description of the Problem > > (1) Overview of Problematic Functions > This section provides an overview of problematic functions, briefly expla= ining their purposes. Following three functions are responsible for handlin= g the bug, broken device fault isolation. two are defined in , and the other is defined in . Function name, lo= cation, and brief explanation for understanding the problem are specified b= elow. > > Function 1. > Source path: linux/mm/memremap.c > [cid:995e2ceb-43a8-4818-a023-9817801ac767] > Function 2. > (called by pagemap_range > add_pages > __add_pages > sparse_add_section >= section_activate) > Source path: linux/mm/sparse.c > [cid:7ce32169-d894-452f-bc90-0036849ce79a] > Function 3. > (called by memremap_pages > section_activate) > Source path: linux/mm/memremap.c > [cid:e90f753d-25b6-465f-b4f8-214ca254da00] > (2) Bug Triggering Flow > Let=E2=80=99s begin with assuming that process A calls memremap_pages wit= h nr_range (the number of pages to allocate) 1. Nit: nr_range is the number of page ranges to allocate (ie. the number of struct range in the flex array), not the number of pages. Each range can contain multiple pages as controlled by range.start/end. > [cid:ec1e9d21-b358-4ff1-af38-da1a43ca7cd0] > > Above flow shows that if allocating memory in 864 line of section_activat= e function fails, the subsection_map masked by process A can never be clear= ed. This is because pageunmap_range is responsible for clearing subsection_= map mask bit, but it can=E2=80=99t be called due to wrong nr_range count. > As the mask bit of subsection_map is not cleared, following call of memre= map_pages from other processes ends up with failure, because given pfn is m= asked as busy by process A. > [cid:993c1924-9680-4981-8b99-0436b7e7a5c7]An error occurred in process A = affects other processes using same pfn, which is usually the case of the pr= ocesses that share the device with process A. The device driver using this = linux kernel api can cause fatal vulnerability in security perspective. For= example, NVIDIA guarantees GPU users a fault isolation between GPU-using p= rocesses. What makes the situation worse in CUDA programming is that checki= ng for GPU errors is the user's responsibility. So, If users believe that G= PU has a robust fault isolation, and uses it like TPM[1] or Security Engine= Accelerator[2, 3], attacker can use this vulnerability to tear down GPU-ba= sed security systems. > (3) Bug usage by an attacker > Followings show how attackers can use this vulnerability, in security per= spective. > [cid:c5b488fa-9ca1-4d44-99f8-847ca63d0387] > This is a classical parallel AES encryption implementation using CUDA, wh= ich tries to accelerate AES encryption through GPU. > Source code is from github repository, https://github.com/allenlee820202/= Parallel-AES-Algorithm-using-CUDA. > This application encrypts strings, =E2=80=9CHello World!=E2=80=9D written= in novel.txt, using AES keys in key.txt. The encryption=E2=80=99s result i= s written into encrypt.txt, and its decryption is written into decrypt.txt. > [cid:b19783df-cf21-4659-9952-0d8ba6d18ad3] > [cid:a12df0c2-01e4-4564-8fee-05d9978abc9f] > You can see that encryption (=E2=80=9CHello world!=E2=80=9D in novel.txt = is encrypted into =E2=80=9Cd5 68 =E2=80=A6 =E2=80=9C in encrypt.txt) works = well. However, in case this bug is triggered by another process using same = GPU driver, the following shows GPU does not work, and encryption fails, re= sulting in plain text is stored in encrypt.txt. > [cid:1920d919-2658-4c49-9add-fa2148f9515e] > (4) Proof of Concept > You can test above cases by following codes. It needs 2 applications to t= rigger the bug. > (4.1) DRAM-overuse application > > #include > > int main(int argc, char* argv[]) > { > while(1) { > int *dummy =3D (int *) malloc (4096); > } > return 0; > } > > (4.2) Normal CUDA-using application > #include > __global__ void cuda_function (float *input) > { > if (blockDim.x * blockIdx.x + threadIdx.x < 512) { > input[blockDim.x * blockIdx.x + threadIdx.x] +=3D 1.0; > } > } > > int main(int argc, char* argv[]) > { > float *input; > float *comp =3D (float *) malloc(512 * sizeof(float)); > cudaMalloc(&input, 512*sizeof(float)); The strange thing here is that cudaMalloc doesn't use the kernel paths mentioned above. > cuda_function<<<16, 32>>>(input); > cudaMemcpy(&comp, input, 512 * sizeof(float), cudaMemcpyDeviceToHost); > return 0; > } > First, multiple DRAM-overuse applications should be executed background, = so that they fill DRAM free area. > Second, While Swap in and out pages frequently occur in DRAM, execute Nor= mal CUDA-using application multiple times. > Third, When CUDA-using application fails its execution due to the bug spe= cified in (4) bug triggering flow, All following applications using CUDA dr= iver cannot be executed normally. > 3. Keywords: device, driver, kernel, memory, allocation > 4. Kernel Version: From Old to Latest Kernel version, All versions are af= fected. > 5. Bug Fix. > Solution is simple. Clearing subsection_map=E2=80=99s mask in section_dea= ctivate with correct nr_range counts, and deleting subsection_map unmasking= role in memunmap_pages can be a solution > > References > [1] PixelVault: Using GPUs for Securing Cryptographic Operations, CCS, 20= 14, Giorgos Vasiliadis, et al. > [2] A framework for GPU-accelerated AES-XTS encryption in mobile devices,= TENCON 2011, Mohammad Ahmed Alomari, et al. > [3] https://github.com/allenlee820202/Parallel-AES-Algorithm-using-CUDA > > Thanks, > Sihyun Roh. > ________________________________ > From: Greg KH > Sent: Tuesday, June 11, 2024 12:05 AM > To: =EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF= =BD / =EF=BF=BD=D0=BB=EF=BF=BD / =EF=BF=BD=EF=BF=BD=EF=BF=BD=E2=A1=A4=EF=BF= =BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=D0=BA=EF=BF=BD > Cc: akpm@linux-foundation.org ; security@kerne= l.org ; linux-mm@kvack.org > Subject: Re: [Linux bug report] A bug breaking device drivers' fault isol= ation guarantees > > On Mon, Jun 10, 2024 at 02:58:16PM +0000, =EF=BF=BD=EF=BF=BD=EF=BF=BD=EF= =BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD / =EF=BF=BD=D0=BB=EF=BF=BD / =EF= =BF=BD=EF=BF=BD=EF=BF=BD=E2=A1=A4=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF= =BD=EF=BF=BD=EF=BF=BD=D0=BA=EF=BF=BD wrote: >> Hi, >> I'm Sihyun Roh, a security researcher at Compsec Lab, Seoul National Uni= versity. >> While testing NVIDIA GPU code, I discovered a minor mistake in the >> Linux kernel code. This issue can cause one process's fault to >> affect other processes, compromising the fault isolation >> guarantee. Given the potential security implications, I am >> forwarding this to the security team as well. >> If you have any questions, feel free to ask. >> Thank you for your efforts in maintaining the Linux kernel code. >> Sincerely, >> Sihyun > > > For obvious reasons we can't open unsolicited .pdf files. Can you send > this in text format? > > And if this is for an out-of-tree kernel driver, there's nothing we can > do about that :( > > thanks, > > greg k-h