Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp3544674ybt; Tue, 23 Jun 2020 05:07:01 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxrSqe2AY/3LSsagt+H5ziGVcpDNmNhhWyRPhOo3KU6/93kdgtAqOSfJFbv67VGualBFqI5 X-Received: by 2002:a17:906:6d15:: with SMTP id m21mr9929278ejr.209.1592914020851; Tue, 23 Jun 2020 05:07:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1592914020; cv=none; d=google.com; s=arc-20160816; b=ItNM4uZP0JtVTnbH5mIMtW8eUTmC3FzfpdxQ7CZh+HwyOAEpnpy87KSvhiakCtr4Ge /VYmcPSS076CR3ioU2dOG07iWlDtRJ8e8rhs7t+qjfQMX2OiuhqbXxv7pqWMvzLiVHDu 6tnL6lIJUHPAKttsOT/HktNcwVsSCFuQ2Hud0hA7Vvs/c0WdjRiKm4FZ1hAbW4C+nCtX HGIxPKAdxRLMxcy+ngVQqEMnBP2Jwcy4ugiQFOl1wfb55V8O+W4jh1kRB6Vj32uXfQ4X X9ZVSoBPMO7lUP+/J9vk3J3uOQPP9XyJq6FXoVaLJEZWDsml7HZzrgJDFlIwx3UenolK tdag== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=DLayW7hbjOReX5nWqJ1XpvcQsXsCV9Xa3paug2YqQ5s=; b=Y7sq6tS0ibQ1oI1zSe50NQI/sQn8JnmRHmv/s5gcCUB3VoWXX2+6zZr3L4LnbcAzA+ sfkCu+mpGrGkqxAF4+tgYdi/6YaptN7SrrEGr97FUBOSiK9/lPHWD92KRsWlNE+SyJ3v X/RZ3DFEY9M6+eN6lQyNm9qhK2uzRbI8+X/Mm5fPyUwDlgLGNSt3AwfNlqYcmRgio525 qVj3N3VV44GTQFJ7TRHwiPN5v3wtWA7Ma2U8VIY5FVLuKigm6WJhxgPWrezGfl28HfQP TO2Uq8KjpGucV23tH7Q0ZZi3BOIWm/GcWnXXhLLS7HCoT+JLWMx9di7Kzk9BupcYiAS1 yEqw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id b27si10881522ejq.568.2020.06.23.05.06.36; Tue, 23 Jun 2020 05:07:00 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732550AbgFWMEi (ORCPT + 99 others); Tue, 23 Jun 2020 08:04:38 -0400 Received: from mx2.suse.de ([195.135.220.15]:38642 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729552AbgFWMEi (ORCPT ); Tue, 23 Jun 2020 08:04:38 -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 D932EAFB0; Tue, 23 Jun 2020 12:04:35 +0000 (UTC) Date: Tue, 23 Jun 2020 14:04:33 +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: <20200623120433.GB14101@suse.de> References: <20200425191032.GK21900@8bytes.org> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200623114818.GD4817@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 01:48:18PM +0200, Peter Zijlstra wrote: > On Tue, Jun 23, 2020 at 01:30:07PM +0200, Joerg Roedel wrote: > But you cannot do a recursion check in #VC, because the NMI can happen > on the first instruction of #VC, before we can increment our counter, > and then the #VC can happen on NMI because the IST stack is a goner, and > we're fscked again (or on a per-cpu variable we touch in our elaborate > NMI setup, etc..). 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. I agree there is no way to keep the system running if that happens, but that is also not what is wanted. If stack recursion happens, something malicious from the HV side is going on, and all the kernel needs to be able to is to safely and reliably detect the situation and panic the VM to prevent any data corruption or loss or even leakage. > I'll keep repeating this, x86_64 exceptions are a trainwreck, and IST in > specific is utter crap. I agree, but don't forget the most prominent underlying reason for IST: The SYSCALL gap. If SYSCALL would switch stacks most of those issues would not exist. IST would still be needed because there are no task gates in x86-64, but still... Regards, Joerg