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 E5477C433EF for ; Mon, 22 Nov 2021 18:02:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 361BF6B0071; Mon, 22 Nov 2021 13:02:20 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2EB3D6B0072; Mon, 22 Nov 2021 13:02:20 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0EF1A6B0073; Mon, 22 Nov 2021 13:02:20 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0082.hostedemail.com [216.40.44.82]) by kanga.kvack.org (Postfix) with ESMTP id EE3826B0071 for ; Mon, 22 Nov 2021 13:02:19 -0500 (EST) Received: from smtpin31.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id A6E5E8A9A8 for ; Mon, 22 Nov 2021 18:02:09 +0000 (UTC) X-FDA: 78837335178.31.07E7947 Received: from NAM02-DM3-obe.outbound.protection.outlook.com (mail-dm3nam07on2049.outbound.protection.outlook.com [40.107.95.49]) by imf30.hostedemail.com (Postfix) with ESMTP id F267AE008BCD for ; Mon, 22 Nov 2021 18:01:38 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=h0HOGvDZLFXtENCCrGN3MV1TOs/g3cdzpOfpaLMIGzacMMQffzUTxBTP+YpGhedNNPsV0Xk2i3V+gow6M+oL8vflXothBNA6p9P9tZwKucrU+ELnttnXbfl7SbsCJVJVZ/nI1mhgZ35A3loTEwrk2qWC2A3HGvn8C+eBF1IL1G1JgyHd5wM3xZA41fU7Y1RPtfXPIuA9821IPOQIyPJsSrduKgSYYexmiK3i8iG0s9uoUcsyWP+aRc9kTRuQYqZgdw7QxR59iSsikIaqaeKMlRcz/1Vs5Fpxy7Ytq35gM1ofXKc0wN52zhV0UKeDSStKup9l6iOSdTWymk4ifs0bfg== 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=OxRc8zdB5sm9t8/iti8opHkQcW3Gm5a/8Hww0+PBDT8=; b=oe83ibWt4MGC2zDWqBYPgyaNiWloAsSMb5AlGgHy46RJnJeSY0dFFBWK+yiZVVHOx83gmGrhbhztxOvuB+eWTeIsks2n9ai/z+dBopOzN0BfCQl1/w9mXizFjXvi1Yp7S01H82tA0ZzGbZ7rqCVnVr/PxbD3liCjFQ14gOgR3qI98yuNFUFIdPsSV2ihfxIPW9SvQ8u4okBPU6xk43jK9y/bZJ64Tl4TCFeAS61rQdlCp8Kjra12GZQGO/iOLULCC0RjGC1IQKSmcOMXkCn+WIn4pVkVfbWE9U+2hWGt0viwQ6OVDizg0od9nKmjp1EKisS8++yRZqFNRrQZRF6ltQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OxRc8zdB5sm9t8/iti8opHkQcW3Gm5a/8Hww0+PBDT8=; b=uOxv3oZExCYvKkUH+Y2BbAUPB9GE24BMEibRi1CrD8Jg+iGwsCFc/28GXohJA5A6noM6XOfgxgTJ1kfqjlFrJhiHhV5JqhqCBo/19c79oIPRkdx6AMeWjdXoNVfKjHfUdlOHiGeVspiOFgbmchd4HYegiRU3B3dGStXdBYoz75g= Received: from SN6PR12MB2718.namprd12.prod.outlook.com (2603:10b6:805:6f::22) by SA0PR12MB4509.namprd12.prod.outlook.com (2603:10b6:806:9e::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4713.19; Mon, 22 Nov 2021 18:01:42 +0000 Received: from SN6PR12MB2718.namprd12.prod.outlook.com ([fe80::e4da:b3ea:a3ec:761c]) by SN6PR12MB2718.namprd12.prod.outlook.com ([fe80::e4da:b3ea:a3ec:761c%7]) with mapi id 15.20.4713.025; Mon, 22 Nov 2021 18:01:42 +0000 Cc: brijesh.singh@amd.com, x86@kernel.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, linux-coco@lists.linux.dev, linux-mm@kvack.org, linux-crypto@vger.kernel.org, Thomas Gleixner , Ingo Molnar , Joerg Roedel , Tom Lendacky , "H. Peter Anvin" , Ard Biesheuvel , Paolo Bonzini , Sean Christopherson , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Andy Lutomirski , Dave Hansen , Sergio Lopez , Peter Zijlstra , Srinivas Pandruvada , David Rientjes , Dov Murik , Tobin Feldman-Fitzthum , Borislav Petkov , Michael Roth , "Kirill A . Shutemov" , Andi Kleen , tony.luck@intel.com, marcorr@google.com, sathyanarayanan.kuppuswamy@linux.intel.com Subject: Re: [PATCH Part2 v5 00/45] Add AMD Secure Nested Paging (SEV-SNP) Hypervisor Support To: Vlastimil Babka , Peter Gonda References: <20210820155918.7518-1-brijesh.singh@amd.com> <6e67f74a-fb4e-fda4-9583-dad28f14ed3a@suse.cz> From: Brijesh Singh Message-ID: <11937ca5-0dc2-d3a0-329b-236345d9f904@amd.com> Date: Mon, 22 Nov 2021 12:01:36 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 In-Reply-To: <6e67f74a-fb4e-fda4-9583-dad28f14ed3a@suse.cz> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US X-ClientProxiedBy: BLAPR03CA0076.namprd03.prod.outlook.com (2603:10b6:208:329::21) To SN6PR12MB2718.namprd12.prod.outlook.com (2603:10b6:805:6f::22) MIME-Version: 1.0 Received: from [10.236.30.107] (165.204.77.1) by BLAPR03CA0076.namprd03.prod.outlook.com (2603:10b6:208:329::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4713.20 via Frontend Transport; Mon, 22 Nov 2021 18:01:38 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 78a3ae89-2924-48cf-27e2-08d9ade2234e X-MS-TrafficTypeDiagnostic: SA0PR12MB4509: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 6tdJoGnU0eXbBLq4UBhxVXFM2erWQXm8JqsZheoTXAg0y+sTh9VqqtzcW/RkFkAeiXVkkHjY5W0UZy/zNi9tRkysSzNNO8OkjNLQDFJT7WnA/aoJmmmYLCBieKfPSEQUph48Qq1sUFf4leVsjqMsmBbeLCKTEHSJ4tPUo9jPxEfwuBKaVFRr3sIMPvplYugCfMj4t5o1jQ+XDqS7ys+0k3eB9ITNuzffCvj/zMJKu3+wDvA+6y7uv/Kl9a8pFV0qbNyWg3f6DZjGlpfyGZsSxOlQtUsHFhnG2HoE42RucBB/wp8aC5ti4sIgQyCS/YO3f2I3E0bNQ58MVtu0Rin0rudVKUCS1TVyc9AaYmOrm16NH2be2FjAQenZwMLS2xvgh2RTrYsUu1YygXJU0jqilVOa92spCNcbZFLRPpX3tUfWTmgoXqyPZnL1nhKQPtSoU0RtWJxPqdRXeiNgt9kWc+JFWL2DKghZ2tr8v4t3yuAfnP7QAy1zye7il8J+hdi7Th3QFFjKu3C+v5jx+2BOmUzvWr1Tg+Em6s6uYZeGLE0PbIucOKVHzPU04S42oGCHHOEfJzT8Xl+kjGm6U8I1bfUvmFN/YxOvn2Q1yMdXx02Xm1/qS1TsU77beE169L+KLNMDOKmySAVlmTqNvRnDvwLMUklBXXgHpRtirrBSBOa3YlCa/XElJBTuJkLskqJFoPt2djUD+u6jq9J8KzOwg6EGKc9nCQUHbiXydb6sXB8p0GpkxdBIkD1XwJTIGIGipvAyUCo9eZAHDDRUc0I08XVJt985Qsvs3Lo39CWlx0s= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SN6PR12MB2718.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(4636009)(366004)(956004)(2616005)(508600001)(5660300002)(86362001)(110136005)(31686004)(44832011)(7406005)(66476007)(66556008)(7416002)(66946007)(36756003)(4326008)(26005)(8936002)(54906003)(31696002)(16576012)(316002)(38100700002)(6486002)(83380400001)(53546011)(2906002)(8676002)(186003)(45980500001)(43740500002);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?VjNaaGx2WXdVMkpBUWJscnNteXBkc2FxNnFCTk1FTi92ajEwb0IveEN4alcx?= =?utf-8?B?R2VQQ1VCZWwzRWd4dG9xS1daU2NTa2o5RHdWa1d1Z0FmOHJ6VzRzdUVmUnhJ?= =?utf-8?B?TTR6TWR4QU9NUG1Za3NMVWhocm1YVnVpN3ZLNkxNOXVEcnFnQmxEdWgxOUJx?= =?utf-8?B?OVlQdjNLUjZMbldibHNnRFRaYVEvRllhRDJzTmFaWXBSbzA2UTBEVzNZWmJo?= =?utf-8?B?WHI3OGRaUnVycUNQUitYYlhpV08vLzF4bW9vYzJBMzFZZlQ3eHhzYXlEcUlC?= =?utf-8?B?bmgva0lwSGtrdk5hZGhFL3ZMbm9pcVRxK1p2UFFMZ3MzQnNOT1RCRDhueEFX?= =?utf-8?B?NW5rZ0JsaFlBRkRDbk1nTWNWNFNuVEh3NFNxOG1pYjNaNWJ1VFl5d3lUazJF?= =?utf-8?B?cVZ6dDZBVU1KdWRNM3Btbm1hZkVrSkNyTXNFN3dkVW1qN2JLTlNWck5FUENz?= =?utf-8?B?Z09yQ2lneW1SekVHc1NlOHFjOTh4SVA5aFNPaVBPaXl0am9LMnNpdHRQMHli?= =?utf-8?B?OEtRWmNCc3JWaWdDei94OHZWYis3K1JubnN6ekxJbHQ3VWJaRVArUWYwcTZP?= =?utf-8?B?TldoeEZWalJPZHJxV0lSL0lFMFR2aUJJVTA4YitWQ0VwTEFVSUl4alN5THNM?= =?utf-8?B?QkRMMWxTdE81WWNjZFZCTEZtUnJWUEs2Y3NUWm51dmVjMU5Bdk1mdzdHTTU0?= =?utf-8?B?RmI0cXBkVmNWVU9sNmJMZWh4S1Nqa0x4N3NhN2dMR29UaytXNnpyME9ONWhT?= =?utf-8?B?VnVxd2g0NUYwb21IQTBTY0VNM0ppQVliSCtiUmFIbFNtSndnMld1RlZNTVBW?= =?utf-8?B?amJSOGdSZ0pXNXpGemZ3bEdnblFHZGRjQ1JWcWt6a00zak41MHl4K0hRS25F?= =?utf-8?B?M3ZtMlNBK21PemtUaVkxZHZSMllTNzdyQ01uRUExMkpBbGZGa3daeTh6bHVE?= =?utf-8?B?N0RiK2I0bDJ0bG41ZzVKTWtaTUJkV2NzTEJvck9GNVcrdjVEZ2h6S3hYT1pn?= =?utf-8?B?Mk5HYjRxMTNHK2pHTHJwMC9LbWg4cjY3THhQV3VpVUZGS1BMK0xlTFlxZXZI?= =?utf-8?B?bFA5RXFPNUVUUGovQkZBeVhDUlNpcElPNC80N2VQbjRROTU3ZlVINWZKOUgy?= =?utf-8?B?YnlVRkYxWWFMS1hpQUNDU2RhczBUZ0xhU1lzUWlqVFZlY1NPZFBmRGxTY2J5?= =?utf-8?B?R2xNV0puRlBhT2RRWWxiZ3ZvU0NUbTNnZUxGQVUyVGltcEJ3ZDY3VEEwa0Jv?= =?utf-8?B?aVJlcjZZOCtSaWtCNHpoZ1Z0SDVaL2pLb1N3dnA1TU95d21wK1I0KzdxU2lu?= =?utf-8?B?ZlpocHVPS2NVdVcxdW5Hc2xrdmkvNC82NjVleDhTUUZta0c2UDZSemh5VjEr?= =?utf-8?B?c1NkT1NzVE5oeUg1ZVhpdDFMRlM2NXdzRk1UamZIV0k2dUY4a3JXcUVNOFUw?= =?utf-8?B?SFpocE0vZkc0WjF1eTlZb3NHY2N5VjFKVEF0ZkwwM3pUbU4vUnc1VW1CaDdz?= =?utf-8?B?ZXZ3K0V1NmJYTitqRTlZcFE3dmZLV2FSZHVnbVN2dnlTUlplSmJDUGNBMHVM?= =?utf-8?B?VTI2SGpSNDF2enFVS3ZCZmxvSnpOSzMrbHRjdC9Ha0c1MmJBRWJOai9kL2F3?= =?utf-8?B?dU85M1pQTitLUGdxbHIvVjkrMXgwOGIyWDhubEZnYjY1UTJYQ1JHL0lrZmJp?= =?utf-8?B?bGV2b1g2M0hzVkFqekZ1Z1Fwbm16eUY4RzhlZzZtdHd1RkpxWm9PUCtSTnZU?= =?utf-8?B?aXdreWxkbFhBaUtYWGxYNVhCaG5LQTcyK3k5dmd0VkFZdEQvbTRnVHVWRWZn?= =?utf-8?B?V1FLRE1yUm5SS0FkNEpCNEFKOE9JWXFuUzNaYkxZbWtjc1BVVEJ2TzBqZXJq?= =?utf-8?B?UlhtMzVPR0tvVzU1L2tjTy9SVGs2TWFxRlV3czlKc1lYTmpVcVdyMk9zdVRV?= =?utf-8?B?SktjclU5OXhnZTVFN0E0NCtkTEpNMzlWWDdSdEtzck1sZzhaanFGN3F5ZUNt?= =?utf-8?B?RGxZa0pOb3BSS2RrVThya3c3SXRvVmpFSUxHYTRvRHFtaHJHNnBQdVNobHJL?= =?utf-8?B?dXlNNnFoSmNhbysxYmloV0FDSlNjSVJxYnZZZFhPcUF6T1FlTGNxRGN6UElV?= =?utf-8?B?dlJCUEFWbnpiYkpIVit6cEYvbEhPSWZ3YUtKTkxCMi9RUlRWWmoxTG42MENS?= =?utf-8?Q?xZtkw38ICR+tE066ykV3JU4=3D?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: 78a3ae89-2924-48cf-27e2-08d9ade2234e X-MS-Exchange-CrossTenant-AuthSource: SN6PR12MB2718.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Nov 2021 18:01:42.3180 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: fx23DdH2VGEtSR2mCib2j+JYX5TEsk6OmhOmjz+mb11XNgjib7yWaZVQKt31T0aBK180lBl+03j0zUJkZK0MYg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR12MB4509 X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: F267AE008BCD Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=amd.com header.s=selector1 header.b=uOxv3oZE; dmarc=pass (policy=quarantine) header.from=amd.com; spf=pass (imf30.hostedemail.com: domain of brijesh.singh@amd.com designates 40.107.95.49 as permitted sender) smtp.mailfrom=brijesh.singh@amd.com X-Stat-Signature: pzentd9hd5yd3jwoaapxime7wm3yswfs X-HE-Tag: 1637604098-595680 Content-Transfer-Encoding: quoted-printable 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: On 11/22/21 11:03 AM, Vlastimil Babka wrote: > On 11/22/21 16:23, Brijesh Singh wrote: >> Hi Peter, >> >> On 11/12/21 9:43 AM, Peter Gonda wrote: >>> Hi Brijesh,, >>> >>> One high level discussion I'd like to have on these SNP KVM patches. >>> >>> In these patches (V5) if a host userspace process writes a guest >>> private page a SIGBUS is issued to that process. If the kernel writes >>> a guest private page then the kernel panics due to the unhandled RMP >>> fault page fault. This is an issue because not all writes into guest >>> memory may come from a bug in the host. For instance a malicious or >>> even buggy guest could easily point the host to writing a private pag= e >>> during the emulation of many virtual devices (virtio, NVMe, etc). For >>> example if a well behaved guests behavior is to: start up a driver, >>> select some pages to share with the guest, ask the host to convert >>> them to shared, then use those pages for virtual device DMA, if a >>> buggy guest forget the step to request the pages be converted to >>> shared its easy to see how the host could rightfully write to private >>> memory. I think we can better guarantee host reliability when running >>> SNP guests without changing SNP=E2=80=99s security properties. >>> >>> Here is an alternative to the current approach: On RMP violation (hos= t >>> or userspace) the page fault handler converts the page from private t= o >>> shared to allow the write to continue. This pulls from s390=E2=80=99s= error >>> handling which does exactly this. See =E2=80=98arch_make_page_accessi= ble()=E2=80=99. >>> Additionally it adds less complexity to the SNP kernel patches, and >>> requires no new ABI. >>> >>> In the current (V5) KVM implementation if a userspace process >>> generates an RMP violation (writes to guest private memory) the >>> process receives a SIGBUS. At first glance, it would appear that >>> user-space shouldn=E2=80=99t write to private memory. However, guaran= teeing >>> this in a generic fashion requires locking the RMP entries (via locks >>> external to the RMP). Otherwise, a user-space process emulating a >>> guest device IO may be vulnerable to having the guest memory >>> (maliciously or by guest bug) converted to private while user-space >>> emulation is happening. This results in a well behaved userspace >>> process receiving a SIGBUS. >>> >>> This proposal allows buggy and malicious guests to run under SNP >>> without jeopardizing the reliability / safety of host processes. This >>> is very important to a cloud service provider (CSP) since it=E2=80=99= s common >>> to have host wide daemons that write/read all guests, i.e. a single >>> process could manage the networking for all VMs on the host. Crashing >>> that singleton process kills networking for all VMs on the system. >>> >> Thank you for starting the thread; based on the discussion, I am keepi= ng the >> current implementation as-is and *not* going with the auto conversion = from >> private to shared. To summarize what we are doing in the current SNP s= eries: >> >> - If userspace accesses guest private memory, it gets SIGBUS. >=20 > So, is there anything protecting host userspace processes from maliciou= s guests? >=20 Unfortunately, no. In the future, we could look into Sean's suggestion to come with an ABI=20 that userspace can use to lock the guest pages before the access and=20 notify the caller of the access violation. It seems that TDX may need=20 something similar, but I cannot tell for sure. This proposal seems good=20 at the first glance but devil is in the detail; once implemented we also=20 need to measure the performance implication of it. Should we consider using SIGSEGV (SEGV_ACCERR) instead of SIGBUS? In=20 other words, treating a guest's private pages as read-only and writing=20 to them will generate a standard SIGSEGV. thanks >> - If kernel accesses[*] guest private memory, it does panic. >> >> [*] Kernel consults the RMP table for the page ownership before the ac= cess. >> If the page is shared, then it uses the locking mechanism to ensure th= at a >> guest will not be able to change the page ownership while kernel has i= t mapped. >> >> thanks >>