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 X-Spam-Level: X-Spam-Status: No, score=-13.6 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id AEC43C433DB for ; Thu, 7 Jan 2021 19:23:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5A68E23443 for ; Thu, 7 Jan 2021 19:23:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729294AbhAGTXl (ORCPT ); Thu, 7 Jan 2021 14:23:41 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45862 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728997AbhAGTXl (ORCPT ); Thu, 7 Jan 2021 14:23:41 -0500 Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F00B9C0612F4 for ; Thu, 7 Jan 2021 11:23:00 -0800 (PST) Received: by mail-pg1-x52c.google.com with SMTP id i7so5626390pgc.8 for ; Thu, 07 Jan 2021 11:23:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=3wrW8bC9EnSUFScXbr/v1leWj3QIh7CSNlwlnFbie1M=; b=AYXeBLs8Mp9jAufPJAEkHwPbo7oWnP4zD/TmgHizl0fFC1aR1DR1uOY4xIpsjCgi0A m4OwMr0Cx4k5s8Wv8ucVMFYiLTW/bBQiPoJAL7RufPo38Jnj1I//ZRX9CfCdEqsPPHPC nty1ovjql/WZnFde6JR8JD6pEtSxh7V1CDFKjSOiXugNDVTpe7NvVYXPEOFZgWJWIDgT p63EmFMRQvVHWdPaCLRlKR8tKzvPqokZTVyatBjJJCH167Uc/8ONofml8vm3H0yj/kre ztFCwCRHZ73ulC1cqIINOu0ASrUAXHAA/qbBq1SNHxCp4tRiJ6UgMadtfggbvNkcHBmV DCHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=3wrW8bC9EnSUFScXbr/v1leWj3QIh7CSNlwlnFbie1M=; b=eAoVzqS7quJ2gUDhF8UB3ChN0GmZCPYLLx35kUt7YdBk6d+1y3OUZdpbXmgW4jHDgo B5+rTqxCyH/TzGROOOOQERIAXLCL1Zcvk+MCFKJk1R8JiG2GuGN5nWBDAVys+y1DE3Of pHK+Y9elcDJtCVraNq2SLjWlQJlSBCGDpMDptxs9XLBAZ3nB7KARv+CzeNkzMAbgIrdq XTht5G2S0+XMziDZmTWAMr1yjfI2IHXSwPUlzqjtw0/lD1BR20F/EoyysM1jr1l0XGg6 VFbcBjktQlx+ZHxCJLbBEDMlmRILP4gF8Yod29xdL+CIi8ZQBIX4KmfpPB8Lqb1tWSse 1ymw== X-Gm-Message-State: AOAM531rey7cZ+/RQYzMU877B8cwi1LbWEXi8zUatg5610TsIaD+IERi eFIkHH5maU2WS2UYWaYZlAsr3w== X-Google-Smtp-Source: ABdhPJwdkbpZp9YH3Tf5cchCh0a7A1tc5kRjDb7subKVPJG/66CrcN6nDTfNCUbuJ1HyKW6taotgCA== X-Received: by 2002:aa7:8b51:0:b029:1ae:687f:d39b with SMTP id i17-20020aa78b510000b02901ae687fd39bmr275421pfd.50.1610047380296; Thu, 07 Jan 2021 11:23:00 -0800 (PST) Received: from google.com ([2620:15c:f:10:1ea0:b8ff:fe73:50f5]) by smtp.gmail.com with ESMTPSA id a141sm6378449pfa.189.2021.01.07.11.22.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Jan 2021 11:22:59 -0800 (PST) Date: Thu, 7 Jan 2021 11:22:52 -0800 From: Sean Christopherson To: Ashish Kalra Cc: Steve Rutherford , "Dr. David Alan Gilbert" , "Singh, Brijesh" , Paolo Bonzini , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , Joerg Roedel , Borislav Petkov , "Lendacky, Thomas" , X86 ML , KVM list , LKML , "dovmurik@linux.vnet.ibm.com" , "tobin@ibm.com" , "jejb@linux.ibm.com" , "frankeh@us.ibm.com" , jon.grimm@amd.com Subject: Re: [PATCH v2 1/9] KVM: x86: Add AMD SEV specific Hypercall3 Message-ID: References: <20201211225542.GA30409@ashkalra_ubuntu_server> <20201212045603.GA27415@ashkalra_ubuntu_server> <20201218193956.GJ2956@work-vm> <20201218195641.GL2956@work-vm> <20210106230555.GA13999@ashkalra_ubuntu_server> <20210107170728.GA16965@ashkalra_ubuntu_server> <20210107184125.GA17388@ashkalra_ubuntu_server> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210107184125.GA17388@ashkalra_ubuntu_server> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jan 07, 2021, Ashish Kalra wrote: > On Thu, Jan 07, 2021 at 09:26:25AM -0800, Sean Christopherson wrote: > > On Thu, Jan 07, 2021, Ashish Kalra wrote: > > > Hello Steve, > > > > > > On Wed, Jan 06, 2021 at 05:01:33PM -0800, Steve Rutherford wrote: > > > > Avoiding an rbtree for such a small (but unstable) list seems correct. > > > > > > > > For the unencrypted region list strategy, the only questions that I > > > > have are fairly secondary. > > > > - How should the kernel upper bound the size of the list in the face > > > > of malicious guests, but still support large guests? (Something > > > > similar to the size provided in the bitmap API would work). > > > > > > I am thinking of another scenario, where a malicious guest can make > > > infinite/repetetive hypercalls and DOS attack the host. > > > > > > But probably this is a more generic issue, this can be done by any guest > > > and under any hypervisor, i don't know what kind of mitigations exist > > > for such a scenario ? > > > > > > Potentially, the guest memory donation model can handle such an attack, > > > because in this model, the hypervisor will expect only one hypercall, > > > any repetetive hypercalls can make the hypervisor disable the guest ? > > > > KVM doesn't need to explicitly bound its tracking structures, it just needs to > > use GFP_KERNEL_ACCOUNT when allocating kernel memory for the structures so that > > the memory will be accounted to the task/process/VM. Shadow MMU pages are the > > only exception that comes to mind; they're still accounted properly, but KVM > > also explicitly limits them for a variety of reasons. > > > > The size of the list will naturally be bounded by the size of the guest; and > > assuming KVM proactively merges adjancent regions, that upper bound is probably > > reasonably low compared to other allocations, e.g. the aforementioned MMU pages. > > > > And, using a list means a malicious guest will get automatically throttled as > > the latency of walking the list (to merge/delete existing entries) will increase > > with the size of the list. > > Just to add here, potentially there won't be any proactive > merging/deletion of existing entries, as the only static entries will be > initial guest MMIO regions, which are contigious guest PA ranges but not > necessarily adjacent. My point was that, if the guest is malicious, eventually there will be adjacent entries, e.g. the worst case scenario is that the encrypted status changes on every 4k page. Anyways, not really all that important, I mostly thinking out loud :-)