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=-11.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable 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 06F7EC47097 for ; Thu, 3 Jun 2021 13:52:38 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E53A76136E for ; Thu, 3 Jun 2021 13:52:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230511AbhFCNyV (ORCPT ); Thu, 3 Jun 2021 09:54:21 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:51570 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230352AbhFCNyU (ORCPT ); Thu, 3 Jun 2021 09:54:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1622728355; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=aGzYnwJ/79uwHhGm7246c+BQzOFvMTF+2K8gC73yhXY=; b=PRs0PZEdcngDjg5rn2TmVCT0JvWyeb1MqnqQuVuU3NKhDVqkgUw3cTZ8WIRgUYuChjzlKg Qb6t/7uUWS7uEfqut4mz6cfriitXh47HDkmdJ4UGqJ8McA0vDr4uukNGSFk+/aFqw1GviI 3w8eVVS+S2qddeARdoqXRJEkmbSMx3w= Received: from mail-ed1-f69.google.com (mail-ed1-f69.google.com [209.85.208.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-552-2BEPgwoiNqmhsz5b3HI0sg-1; Thu, 03 Jun 2021 09:52:33 -0400 X-MC-Unique: 2BEPgwoiNqmhsz5b3HI0sg-1 Received: by mail-ed1-f69.google.com with SMTP id y18-20020a0564022712b029038ffac1995eso3313578edd.12 for ; Thu, 03 Jun 2021 06:52:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=aGzYnwJ/79uwHhGm7246c+BQzOFvMTF+2K8gC73yhXY=; b=OPSkLxFg9L8D0pI4pxJ4slWOR+aFaIctgVrBcEzTDnP6p96Q+D3+/N2WkuNb8eEDi+ zO4qz2X2yzult7kjRkHcO4mtOzeyezR4BKUDoLHNtjnPKpJmeA/ASyac+FyAgEwBFxGU wThtPeCQ1S2vutPbRnRQnvqnH236o03+5ZKfrnSXLDLk4iueVN8+AgvcRYc7WQPSO/YF oRQlY/Eo9hvctDgUv4aJA0P3BUGHCUEZAiHH/e9u1anR5Uk2Cb+sJeSq1gu7WcccaWHF tdQVm2Ifixt8GMmPGXkL1/jaz7uUj/XgECYt8D2F4k9nY6Fu3tODqqbzo4cqXqZfNyHA Db+Q== X-Gm-Message-State: AOAM533bomPtL68o76S0QdrKvijGR7TuP+WwfG+f+6SnfR60fpx1lLgc nrTPjqsexxjBdAa/9OgdKWt55orpQLgy9n63UTYpx6xrcgsjSM4gAYYedFV3ImtSJ6mcVvkn6CH 1OIjM5SHyL4q7hmkjywKjr9+z X-Received: by 2002:aa7:db94:: with SMTP id u20mr43820035edt.381.1622728352472; Thu, 03 Jun 2021 06:52:32 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxFTkGs1V14Wf6MLgMSIw4+iLzsxca6I0DcvG4KjZ50QkzIyM+lKtiGeOU4iF2LT4KYVoFfPA== X-Received: by 2002:aa7:db94:: with SMTP id u20mr43820025edt.381.1622728352333; Thu, 03 Jun 2021 06:52:32 -0700 (PDT) Received: from vitty.brq.redhat.com (g-server-2.ign.cz. [91.219.240.2]) by smtp.gmail.com with ESMTPSA id p7sm1824947edw.43.2021.06.03.06.52.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 03 Jun 2021 06:52:31 -0700 (PDT) From: Vitaly Kuznetsov To: Xiaoyao Li , Tao Xu Cc: x86@kernel.org, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, pbonzini@redhat.com, seanjc@google.com, wanpengli@tencent.com, jmattson@google.com, joro@8bytes.org, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, hpa@zytor.com Subject: Re: [PATCH v2] KVM: VMX: Enable Notify VM exit In-Reply-To: <660ceed2-7569-6ce6-627a-9a4e860b8aa9@intel.com> References: <20210525051204.1480610-1-tao3.xu@intel.com> <871r9k36ds.fsf@vitty.brq.redhat.com> <660ceed2-7569-6ce6-627a-9a4e860b8aa9@intel.com> Date: Thu, 03 Jun 2021 15:52:30 +0200 Message-ID: <87fsxz12e9.fsf@vitty.brq.redhat.com> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Xiaoyao Li writes: > On 6/2/2021 6:31 PM, Vitaly Kuznetsov wrote: >> Tao Xu writes: >> >>> There are some cases that malicious virtual machines can cause CPU stuck >>> (event windows don't open up), e.g., infinite loop in microcode when >>> nested #AC (CVE-2015-5307). No event window obviously means no events, >>> e.g. NMIs, SMIs, and IRQs will all be blocked, may cause the related >>> hardware CPU can't be used by host or other VM. >>> >>> To resolve those cases, it can enable a notify VM exit if no event >>> window occur in VMX non-root mode for a specified amount of time >>> (notify window). Since CPU is first observed the risk of not causing >>> forward progress, after notify window time in a units of crystal clock, >>> Notify VM exit will happen. Notify VM exit can happen incident to delivery >>> of a vectored event. >>> >>> Expose a module param for configuring notify window, which is in unit of >>> crystal clock cycle. >>> - A negative value (e.g. -1) is to disable this feature. >>> - Make the default as 0. It is safe because an internal threshold is added >>> to notify window to ensure all the normal instructions being coverd. >>> - User can set it to a large value when they want to give more cycles to >>> wait for some reasons, e.g., silicon wrongly kill some normal instruction >>> due to internal threshold is too small. >>> >>> Notify VM exit is defined in latest Intel Architecture Instruction Set >>> Extensions Programming Reference, chapter 9.2. >>> >>> Co-developed-by: Xiaoyao Li >>> Signed-off-by: Xiaoyao Li >>> Signed-off-by: Tao Xu >>> --- >>> >>> Changelog: >>> v2: >>> Default set notify window to 0, less than 0 to disable. >>> Add more description in commit message. >> >> Sorry if this was already discussed, but in case of nested >> virtualization and when L1 also enables >> SECONDARY_EXEC_NOTIFY_VM_EXITING, shouldn't we just reflect NOTIFY exits >> during L2 execution to L1 instead of crashing the whole L1? >> > > yes. If we expose it to nested, it should reflect the Notify VM exit to > L1 when L1 enables it. > > But regarding nested, there are more things need to be discussed. e.g., > 1) It has dependence between L0 and L1, for security consideration. When > L0 enables it, it shouldn't be turned off during L2 VM is running. > a. Don't expose to L1 but enable for L1 when L2 VM is running. > b. expose it to L1 and force it enabled. Could you please elaborate on the 'security' concern? My understanding that during L2 execution: If L0 enables the feature and L1 doesn't, vmexit goes to L0. If L1 enables the feature and L0 doesn't, vmexit goes to L1. If both L0 and L1 enable the feature, vmexit can probably (I didn't put enough though in it I'm afraid) go to the one which has smaller window. > > 2) When expose it to L1, vmcs02.notify_window needs to be > min(L0.notify_window, L1.nofity_window) > > We don't deal with nested to make this Patch simple. Sure, I just wanted to check with you what's the future plan and if the behavior you introduce is desireable in nested case. -- Vitaly