Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp381266pxf; Wed, 10 Mar 2021 08:10:27 -0800 (PST) X-Google-Smtp-Source: ABdhPJxkVjpRYa5ifzzML6LSbu5ojo+WIANBmYKkPJ34G1RbufK2HGu5fhYapnmVSV9XfrJHXCaZ X-Received: by 2002:a17:906:a896:: with SMTP id ha22mr4359333ejb.503.1615392627627; Wed, 10 Mar 2021 08:10:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1615392627; cv=none; d=google.com; s=arc-20160816; b=fvlA14TYtevw743ZRtQkqK7wjRS9FeCS/IcecZdI0C63gb4lCp/J2LmW0e14/U47xg UqTKv8E978Sx9W8ezqVxPi536fX38cBVujNLFmUqo+DlWiJMqsXrdrRmkkt43/iKVdwZ BLbGXV1QuZV3Gq9X2OP2rynQcykX0M9JZWPRuPVt6tM98gwXdrhfE19ueJfoPrFqnbCf 81CVoLbLfPSm50JXTtQ6D9jtRPGElBzXi1GD3PLqWz4C7IvMw0WN+WyIUWXrUpSVLAH0 9u+M4sagYOMDzSfmmpopqtvoPSSybcBMnn2RvSgiPB6QNbRJE4vGROAUCS5o6BW/ZJ3a w99Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=n5SUJ6SxBX80zMdF1n9kHJvTdoHW9bhKWhAVahClOnw=; b=Llvc5UuVywAUHhl0iyxau287LSI4yZEWtQogwIrpXcCuXegKdiMHMk/ncZsfeRviq4 +qIhG84SnWHeu3uFdiX9fbFXZiwkS5xzynCmbm7nQWVTAyjKWPGJCCnZ8M+q1iobM4di tc0KyZVVJD+Q3a8OJ+aZTJHUM0xMRa+mnXqaZ8nxlKxHnJ6zALh9Iri9zIcj43Z2a4/d b/22h75KAVCwDWteXBhZaAcPT1Wqmd7hrXTBxO3+P1Hyx0mgqSx/qPHXwYawwAFr6FAB e3TBDdM77l3jmw3/T7BHhIVLOZgzzKTTW3pwPfi0tps57zFOsYrs5S697GQRlkbHh4Pj SQvg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=CWTtLzbp; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g11si12230308ejd.733.2021.03.10.08.09.59; Wed, 10 Mar 2021 08:10:27 -0800 (PST) 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; dkim=pass header.i=@google.com header.s=20161025 header.b=CWTtLzbp; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231985AbhCJQIx (ORCPT + 99 others); Wed, 10 Mar 2021 11:08:53 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53308 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231689AbhCJQIr (ORCPT ); Wed, 10 Mar 2021 11:08:47 -0500 Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 251B5C061760 for ; Wed, 10 Mar 2021 08:08:47 -0800 (PST) Received: by mail-pg1-x533.google.com with SMTP id o38so11687796pgm.9 for ; Wed, 10 Mar 2021 08:08:47 -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=n5SUJ6SxBX80zMdF1n9kHJvTdoHW9bhKWhAVahClOnw=; b=CWTtLzbpRE0V6DoYNY5ITdORUBJw8jR4RCevgqlelCN+8kUmrRzlTLdFdG4a/eMvz2 ZrVuOTckkKqFhXKDwA1CP/ArmUcQpwL+VQlD499zZ1ZUR+pPtJZyT63QpFgeUNGjFEwr FQ7GRQDp/0r38umVI6oWVOHtPyGT+vGswax9+1eh97CaZ81ynX5x+JNdkTxsZLhKM50O 1ShZYqKP38mYycHxl3jRlhy6hXAflEwBjO0IKlVRRc3eVO9hx7kemvMjmD7/PZoSDDIu IiefWTdhxFmCxahCznDHWM8FVVIbG0hzEUu4GGRXhBraxl2ygu6ILYeHWzuWAuqk1as3 dvfA== 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=n5SUJ6SxBX80zMdF1n9kHJvTdoHW9bhKWhAVahClOnw=; b=enXZlvS9v+0Zp2ChjbtKuBtJmwJ9G/vUulPX0/+WGYTBzMfFuSEK8Q7YfsisC85kY2 xsmzHMMWsl5RDKFeX8JecmFbwhr9F8d/p+B1bqrELCKK0bD9iOKnxbKRwhG8nllYuBA7 IgWznNLOwMA6x6Wr/BtEpECrJtZiagiDH7aswnEC6LjaAwjIPsFD7L+js3C07ymhGDMJ QLzsATvFlJ3g3z6a0Ufp/IwFiCJtkYp9dNvYKbkO6UTOBgyZvfHkBcdE+H91JKM5Li27 dz+cgAxLrOp4Q+WeOmFZrvUHcT0rn22N31u7YML4GrnKcoDbFFbP4WNcIiohQUpszS7B rixQ== X-Gm-Message-State: AOAM531Pv5JUcjwE9/LxMq6ZrEq2igygfyfidClXCcg3qK9JU/I+NH// cz6q8pLYEkDvIgINXwqVAxhd0Q== X-Received: by 2002:a63:ff53:: with SMTP id s19mr3403048pgk.347.1615392526495; Wed, 10 Mar 2021 08:08:46 -0800 (PST) Received: from google.com ([2620:15c:f:10:e4dd:6c31:9463:f8da]) by smtp.gmail.com with ESMTPSA id x7sm5308pfp.23.2021.03.10.08.08.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 10 Mar 2021 08:08:45 -0800 (PST) Date: Wed, 10 Mar 2021 08:08:37 -0800 From: Sean Christopherson To: Joerg Roedel Cc: x86@kernel.org, Joerg Roedel , hpa@zytor.com, Andy Lutomirski , Dave Hansen , Peter Zijlstra , Jiri Slaby , Dan Williams , Tom Lendacky , Juergen Gross , Kees Cook , David Rientjes , Cfir Cohen , Erdem Aktas , Masami Hiramatsu , Mike Stunes , Martin Radev , Arvind Sankar , linux-kernel@vger.kernel.org, kvm@vger.kernel.org, virtualization@lists.linux-foundation.org Subject: Re: [PATCH v2 5/7] x86/boot/compressed/64: Add CPUID sanity check to 32-bit boot-path Message-ID: References: <20210310084325.12966-1-joro@8bytes.org> <20210310084325.12966-6-joro@8bytes.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210310084325.12966-6-joro@8bytes.org> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 10, 2021, Joerg Roedel wrote: > From: Joerg Roedel > > The 32-bit #VC handler has no GHCB and can only handle CPUID exit codes. > It is needed by the early boot code to handle #VC exceptions raised in > verify_cpu() and to get the position of the C bit. > > But the CPUID information comes from the hypervisor, which is untrusted > and might return results which trick the guest into the no-SEV boot path > with no C bit set in the page-tables. All data written to memory would > then be unencrypted and could leak sensitive data to the hypervisor. > > Add sanity checks to the 32-bit boot #VC handler to make sure the > hypervisor does not pretend that SEV is not enabled. > > Signed-off-by: Joerg Roedel > --- > arch/x86/boot/compressed/mem_encrypt.S | 36 ++++++++++++++++++++++++++ > 1 file changed, 36 insertions(+) > > diff --git a/arch/x86/boot/compressed/mem_encrypt.S b/arch/x86/boot/compressed/mem_encrypt.S > index 2ca056a3707c..8941c3a8ff8a 100644 > --- a/arch/x86/boot/compressed/mem_encrypt.S > +++ b/arch/x86/boot/compressed/mem_encrypt.S > @@ -145,6 +145,34 @@ SYM_CODE_START(startup32_vc_handler) > jnz .Lfail > movl %edx, 0(%esp) # Store result > > + /* > + * Sanity check CPUID results from the Hypervisor. See comment in > + * do_vc_no_ghcb() for more details on why this is necessary. > + */ > + > + /* Fail if Hypervisor bit not set in CPUID[1].ECX[31] */ This check is flawed, as is the existing check in 64-bit boot. Or I guess more accurately, the check in get_sev_encryption_bit() is flawed. AIUI, SEV-ES doesn't require the hypervisor to intercept CPUID. A malicious hypervisor can temporarily pass-through CPUID to bypass the CPUID[1].ECX[31] check. The hypervisor likely has access to the guest firmware source, so it wouldn't be difficult for the hypervisor to disable CPUID interception once it detects that firmware is handing over control to the kernel. > + cmpl $1, %ebx > + jne .Lcheck_leaf > + btl $31, 4(%esp) > + jnc .Lfail > + jmp .Ldone > + > +.Lcheck_leaf: > + /* Fail if SEV leaf not available in CPUID[0x80000000].EAX */ > + cmpl $0x80000000, %ebx > + jne .Lcheck_sev > + cmpl $0x8000001f, 12(%esp) > + jb .Lfail > + jmp .Ldone > + > +.Lcheck_sev: > + /* Fail if SEV bit not set in CPUID[0x8000001f].EAX[1] */ > + cmpl $0x8000001f, %ebx > + jne .Ldone > + btl $1, 12(%esp) > + jnc .Lfail > + > +.Ldone: > popl %edx > popl %ecx > popl %ebx > @@ -158,6 +186,14 @@ SYM_CODE_START(startup32_vc_handler) > > iret > .Lfail: > + /* Send terminate request to Hypervisor */ > + movl $0x100, %eax > + xorl %edx, %edx > + movl $MSR_AMD64_SEV_ES_GHCB, %ecx > + wrmsr > + rep; vmmcall > + > + /* If request fails, go to hlt loop */ > hlt > jmp .Lfail > SYM_CODE_END(startup32_vc_handler) > -- > 2.30.1 >