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=-2.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 97726C433E0 for ; Tue, 23 Jun 2020 13:40:09 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6F5DE20720 for ; Tue, 23 Jun 2020 13:40:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732709AbgFWNkI (ORCPT ); Tue, 23 Jun 2020 09:40:08 -0400 Received: from mx2.suse.de ([195.135.220.15]:59130 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732631AbgFWNkH (ORCPT ); Tue, 23 Jun 2020 09:40:07 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 6A681ACF2; Tue, 23 Jun 2020 13:40:05 +0000 (UTC) Date: Tue, 23 Jun 2020 15:40:03 +0200 From: Joerg Roedel To: Peter Zijlstra Cc: Andy Lutomirski , Joerg Roedel , Dave Hansen , Tom Lendacky , Mike Stunes , Dan Williams , Dave Hansen , "H. Peter Anvin" , Juergen Gross , Jiri Slaby , Kees Cook , kvm list , LKML , Thomas Hellstrom , Linux Virtualization , X86 ML , Sean Christopherson , Andrew Cooper Subject: Re: Should SEV-ES #VC use IST? (Re: [PATCH] Allow RDTSC and RDTSCP from userspace) Message-ID: <20200623134003.GD14101@suse.de> References: <910AE5B4-4522-4133-99F7-64850181FBF9@amacapital.net> <20200425202316.GL21900@8bytes.org> <20200428075512.GP30814@suse.de> <20200623110706.GB4817@hirez.programming.kicks-ass.net> <20200623113007.GH31822@suse.de> <20200623114818.GD4817@hirez.programming.kicks-ass.net> <20200623120433.GB14101@suse.de> <20200623125201.GG4817@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200623125201.GG4817@hirez.programming.kicks-ass.net> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 23, 2020 at 02:52:01PM +0200, Peter Zijlstra wrote: > On Tue, Jun 23, 2020 at 02:04:33PM +0200, Joerg Roedel wrote: > > No, the recursion check is fine, because overwriting an already used IST > > stack doesn't matter (as long as it can be detected) if we are going to > > panic anyway. It doesn't matter because the kernel will not leave the > > currently running handler anymore. > > You only have that guarantee when any SNP #VC from kernel is an > automatic panic. But in that case, what's the point of having the > recursion count? It is not a recursion count, it is a stack-recursion check. Basically walk down the stack and look if your current stack is already in use. Yes, this can be optimized, but that is what is needed. IIRC the current prototype code for SNP just pre-validates all memory in the VM and doesn't support moving pages around on the host. So any #VC SNP exception would be fatal, yes. In a scenario with on-demand validation of guest pages and support for guest-assisted page-moving on the HV side it would be more complicated. Basically all memory that is accessed during #VC exception handling must stay validated at all times, including the IST stack. So saying this, I don't understand why _all_ SNP #VC exceptions from kernel space must be fatal? Regards, Joerg From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joerg Roedel Subject: Re: Should SEV-ES #VC use IST? (Re: [PATCH] Allow RDTSC and RDTSCP from userspace) Date: Tue, 23 Jun 2020 15:40:03 +0200 Message-ID: <20200623134003.GD14101@suse.de> References: <910AE5B4-4522-4133-99F7-64850181FBF9@amacapital.net> <20200425202316.GL21900@8bytes.org> <20200428075512.GP30814@suse.de> <20200623110706.GB4817@hirez.programming.kicks-ass.net> <20200623113007.GH31822@suse.de> <20200623114818.GD4817@hirez.programming.kicks-ass.net> <20200623120433.GB14101@suse.de> <20200623125201.GG4817@hirez.programming.kicks-ass.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <20200623125201.GG4817@hirez.programming.kicks-ass.net> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: virtualization-bounces@lists.linux-foundation.org Sender: "Virtualization" To: Peter Zijlstra Cc: Juergen Gross , Tom Lendacky , Thomas Hellstrom , X86 ML , Mike Stunes , Kees Cook , kvm list , Andrew Cooper , Joerg Roedel , Dave Hansen , LKML , Sean Christopherson , Linux Virtualization , Dave Hansen , Andy Lutomirski , "H. Peter Anvin" , Dan Williams , Jiri Slaby List-Id: virtualization@lists.linuxfoundation.org On Tue, Jun 23, 2020 at 02:52:01PM +0200, Peter Zijlstra wrote: > On Tue, Jun 23, 2020 at 02:04:33PM +0200, Joerg Roedel wrote: > > No, the recursion check is fine, because overwriting an already used IST > > stack doesn't matter (as long as it can be detected) if we are going to > > panic anyway. It doesn't matter because the kernel will not leave the > > currently running handler anymore. > > You only have that guarantee when any SNP #VC from kernel is an > automatic panic. But in that case, what's the point of having the > recursion count? It is not a recursion count, it is a stack-recursion check. Basically walk down the stack and look if your current stack is already in use. Yes, this can be optimized, but that is what is needed. IIRC the current prototype code for SNP just pre-validates all memory in the VM and doesn't support moving pages around on the host. So any #VC SNP exception would be fatal, yes. In a scenario with on-demand validation of guest pages and support for guest-assisted page-moving on the HV side it would be more complicated. Basically all memory that is accessed during #VC exception handling must stay validated at all times, including the IST stack. So saying this, I don't understand why _all_ SNP #VC exceptions from kernel space must be fatal? Regards, Joerg