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=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 EBCD3C4332D for ; Thu, 19 Mar 2020 18:43:36 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id BF00A20787 for ; Thu, 19 Mar 2020 18:43:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1584643416; bh=16Mv0Bki/NfvJX5iwDxd/8tDdJeb33292LnGanZEgHk=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=jgPILBBakyWYIiHydVX/eXL3U3ouh+qGEAGt04REbwEhYPdLfnrlhCYHfNK27jawm qe6ZJsYU7KmSh5pXzxh4CqONVD1iTxWPdhLfKOlq/vwBAI8FgtsdMa23kYF1LwRpVP pY6iJsc14ALvMa8YSm1BqDzntu+BWCCh+otq8JVE= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727393AbgCSSnf (ORCPT ); Thu, 19 Mar 2020 14:43:35 -0400 Received: from mail.kernel.org ([198.145.29.99]:34070 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725787AbgCSSnf (ORCPT ); Thu, 19 Mar 2020 14:43:35 -0400 Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 2E3FE208E4 for ; Thu, 19 Mar 2020 18:43:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1584643414; bh=16Mv0Bki/NfvJX5iwDxd/8tDdJeb33292LnGanZEgHk=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=gZnE0N1zX3N4hrpdEBg3hayONMFggbn4LZXMYyZpsRN0k2dZjof1Jfd1Qmvhdh93+ sGF9hoGmQ3D9O6lCKLVt/Fn4A0XRLnor5uOC07hgnzJMuGptsX7jsAEzADkZqINynv dtZbN5mYI74zyy3gDrcqFJNyDt6bH15ZmZzbPenY= Received: by mail-wm1-f50.google.com with SMTP id d1so3578708wmb.2 for ; Thu, 19 Mar 2020 11:43:34 -0700 (PDT) X-Gm-Message-State: ANhLgQ3dKMJNm/28MNKF/IBrU5UTL0BRmVihKwSyKSapWPFHbhIL5nyT SXltR5CLByjlzj+oVsoPbKBi3qwTqOTA1zhVvjl+vw== X-Google-Smtp-Source: ADFU+vv10cBd6Yipt9Fp30VfQsiUak847hkVmmyNfiLI7ndWg3gIIQhdPQtda5z9gYC13rmpADmNaW86Fu4VfLkwdyA= X-Received: by 2002:a1c:1904:: with SMTP id 4mr765861wmz.21.1584643412632; Thu, 19 Mar 2020 11:43:32 -0700 (PDT) MIME-Version: 1.0 References: <20200319091407.1481-1-joro@8bytes.org> <20200319091407.1481-42-joro@8bytes.org> <20200319162439.GE5122@8bytes.org> In-Reply-To: <20200319162439.GE5122@8bytes.org> From: Andy Lutomirski Date: Thu, 19 Mar 2020 11:43:20 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 41/70] x86/sev-es: Add Runtime #VC Exception Handler To: Joerg Roedel Cc: Andy Lutomirski , X86 ML , "H. Peter Anvin" , Dave Hansen , Peter Zijlstra , Thomas Hellstrom , Jiri Slaby , Dan Williams , Tom Lendacky , Juergen Gross , Kees Cook , LKML , kvm list , Linux Virtualization , Joerg Roedel Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Mar 19, 2020 at 9:24 AM Joerg Roedel wrote: > > On Thu, Mar 19, 2020 at 08:44:03AM -0700, Andy Lutomirski wrote: > > On Thu, Mar 19, 2020 at 2:14 AM Joerg Roedel wrote: > > > > > > From: Tom Lendacky > > > > > > Add the handler for #VC exceptions invoked at runtime. > > > > If I read this correctly, this does not use IST. If that's true, I > > don't see how this can possibly work. There at least two nasty cases > > that come to mind: > > > > 1. SYSCALL followed by NMI. The NMI IRET hack gets to #VC and we > > explode. This is fixable by getting rid of the NMI EFLAGS.TF hack. > > Not an issue in this patch-set, the confusion comes from the fact that I > left some parts of the single-step-over-iret code in the patch. But it > is not used. The NMI handling in this patch-set sends the NMI-complete > message before the IRET, when the kernel is still in a safe environment > (kernel stack, kernel cr3). Got it! > > > 2. tools/testing/selftests/x86/mov_ss_trap_64. User code does MOV > > (addr), SS; SYSCALL, where addr has a data breakpoint. We get #DB > > promoted to #VC with no stack. > > Also not an issue, as debugging is not supported at the moment in SEV-ES > guests (hardware has no way yet to save/restore the debug registers > across #VMEXITs). But this will change with future hardware. If you look > at the implementation for dr7 read/write events, you see that the dr7 > value is cached and returned, but does not make it to the hardware dr7. Eek. This would probably benefit from some ptrace / perf logic to prevent the kernel or userspace from thinking that debugging works. I guess this means that #DB only happens due to TF or INT01. I suppose this is probably okay. > > I though about using IST for the #VC handler, but the implications for > nesting #VC handlers made me decide against it. But for future hardware > that supports debugging inside SEV-ES guests it will be an issue. I'll > think about how to fix the problem, it probably has to be IST :( Or future generations could have enough hardware support for debugging that #DB doesn't need to be intercepted or can be re-injected correctly with the #DB vector. > > Regards, > > Joerg