Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp3812817pxu; Tue, 20 Oct 2020 00:44:54 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyHe5ZC8GvTB6mLfnvh97ULRhQcuCFdac4yQSGZGTzSsKElGH12Mbs2wnRrTLM+fuHiGcW0 X-Received: by 2002:a50:d654:: with SMTP id c20mr1534171edj.54.1603179894209; Tue, 20 Oct 2020 00:44:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1603179894; cv=none; d=google.com; s=arc-20160816; b=WE6KCF69KhEy34jBkF1kAjfyIp9CUsttMbs3dsS61OCKs8u9d4OyLFx3VbvSMKGYKa 7PAb7XvRVYN60vqoQWA+fHPmf5pJZvBfixrIQATVGJHuN54EqrXzAikEDNckD0HnYgrm 78Nd15ifBlybDNbsZIFIldbJ9H+Ed89JSPObTQnGeKWSTqK8Lil8pwP+uYLt92pG5mys SY8CHFyFVxNg9cYpyv74mOy6WUaTvYgOVcRRi8bbEtgdA8e945t7xV4MfIdRrR/d+ljb I4vK66m3fdYfGsG8CNYJjuxMPYgPbuZYkdD05LduMc/q8ZCFA/ZMcvsZaQ6FtBVz88mX Kx2g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=7ZJ7L6my96fM0G4yUHOA7jI9tSfQTb15aB7OWISVJOg=; b=qKKhHUO/MO5qFgYDdrh9qj0iKTE3Qoz7LZjN+KAu2po1GZvzP9N9iII5P7wV693hWa Wkt7ayJwvh8zgLHj0lg2VdMD/2L3n6FeRocHg+Q4/s+X7Qy0nDD3Dpqu5vSmGe5eVBj+ sezF1e6f29z19A/MFmJyeyYENlrXDlVgZkfkQ6b/7jiWN9gNMZ8UVCKyMM/cAEdz1dDY 9+U1qDX/U2FD7JIOrUv/QMal+GhNa67AAlUV2ElrEbiKlBdQp/tU47obJ87Ik9nDl/a3 SlexGc2teJ0/L3rrXt+rhnm5ua+YRRoxbYNp56PYF+Nrf9J/syNisGB+UXt8Tkrjx8GO cllg== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=8bytes.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id r16si707103ejs.21.2020.10.20.00.44.32; Tue, 20 Oct 2020 00:44:54 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=8bytes.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730228AbgJSUji (ORCPT + 99 others); Mon, 19 Oct 2020 16:39:38 -0400 Received: from 8bytes.org ([81.169.241.247]:34062 "EHLO theia.8bytes.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725823AbgJSUji (ORCPT ); Mon, 19 Oct 2020 16:39:38 -0400 Received: by theia.8bytes.org (Postfix, from userid 1000) id AE03E52D; Mon, 19 Oct 2020 22:39:36 +0200 (CEST) Date: Mon, 19 Oct 2020 22:39:35 +0200 From: Joerg Roedel To: Arvind Sankar Cc: x86@kernel.org, Joerg Roedel , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , Dave Hansen , Andy Lutomirski , Peter Zijlstra , Kees Cook , Martin Radev , Tom Lendacky , linux-kernel@vger.kernel.org Subject: Re: [PATCH 3/5] x86/boot/compressed/64: Check SEV encryption in 64-bit boot-path Message-ID: <20201019203935.GG3635@8bytes.org> References: <20201019151121.826-1-joro@8bytes.org> <20201019151121.826-4-joro@8bytes.org> <20201019170008.GA2701355@rani.riverdale.lan> <20201019175447.GA2720155@rani.riverdale.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201019175447.GA2720155@rani.riverdale.lan> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Oct 19, 2020 at 01:54:47PM -0400, Arvind Sankar wrote: > Also, isn't it possible that the initial page tables we're running on > have already been messed with and have the C-bit in the wrong location, > so that this write happens decrypted? The code assumes that the page-table it is running on has the correct C bit position set and that the code which set it up verified that it is correct. For the kernel itself this is true, at least, but when booting via UEFI the check also needs to happen in the firmware. Note that the possibilies are limited when the hypervisor reports the wrong C bit position because code fetches always assume encryption, even when the C bit is cleared in the page-table. So a wrong C bit position in the decompression stub would write the kernel image to memory unencrypted and executing it would not be possible. Regards, Joerg