Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp4623230pxu; Wed, 21 Oct 2020 00:39:12 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyzwhejWaJy3yLCUADvA8Dkza90ON73iXbBiQvtDvzIiv/DXcdJn2D2bRSMkYGB6fWoANRo X-Received: by 2002:a17:906:4c4c:: with SMTP id d12mr2020246ejw.299.1603265952392; Wed, 21 Oct 2020 00:39:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1603265952; cv=none; d=google.com; s=arc-20160816; b=Dfmee6u+16hsqkOAqnwmopUdIfivfUygrauSa8QjEGVoNcO4mt0q9aKgrSk0cUwSKE Cfw1LOEQfH+bfCPKIZg+0jpP6pKVtIghpIKffNb9AcO72VImhDvnp0z+M9YBwtSAuEOS NscEoBHYfNtbbng2qnMEOwqmUZhe4eGz8PM2J8xUUkcuy8uMTb0Oa4dWYYE9o/S65mIw 9YLkqQfCGWtU7GheNR2Kipj+SO+mWmWF8Cxp4lIAn3/UNMOSVDwFd14zqeraYnegbqVN 6mtjiIdJvpLua4VwA9z9B3hcB+cVE8gor5zKCpRfC/BLiVTGHVA88Jstg7Ps05wG0aS+ 9+5A== 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:date:from:sender:dkim-signature; bh=jj9glYe0gvbVcAodw3qv6Kp672I6hibQ7u2mjdDL0BQ=; b=alivfzx+Xs6f/M6GLJ4oTrDySigPge7XUYdtglJ7VtOKcq0TPE9yDsPYvWIyIi78Hi ODlvSeGzU1YdV+hvprHKqk/pETwzXOOvRIu9jR9/oJ1b39HSZuSn7Dz/6w8sXxsNhmSC Uq6g7urMWs7PEg8nml70ZWbeB0TtLnHVSgF8v8Yg/gXJwgD03tYByWF7vrsM3Aq5kBlP U/idI/g4Z53e5/HhTBqciDsnlScUtTb5rysPZz0sHgpsiWUUvRVVuXF5UYBW3uaort3v x1M4dJ7d4+VXG9OOOCmNMY6XyjBCsYegLy6/K1Bx97ncmEhmqBeqCzRjp2uX9FSTFRdY /Vig== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=FDIUTpY+; 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 x22si825290edr.405.2020.10.21.00.38.50; Wed, 21 Oct 2020 00:39:12 -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; dkim=pass header.i=@gmail.com header.s=20161025 header.b=FDIUTpY+; 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 S2408141AbgJTOdS (ORCPT + 99 others); Tue, 20 Oct 2020 10:33:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40872 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2408012AbgJTOdS (ORCPT ); Tue, 20 Oct 2020 10:33:18 -0400 Received: from mail-il1-x143.google.com (mail-il1-x143.google.com [IPv6:2607:f8b0:4864:20::143]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C4946C061755 for ; Tue, 20 Oct 2020 07:33:16 -0700 (PDT) Received: by mail-il1-x143.google.com with SMTP id j13so2507553ilc.4 for ; Tue, 20 Oct 2020 07:33:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:date:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=jj9glYe0gvbVcAodw3qv6Kp672I6hibQ7u2mjdDL0BQ=; b=FDIUTpY+EczYabB3zudGGYlm2bXqozLmyLzyoExIYHR74w7QRpS4sJspfDnhCBQCrZ rDd6xn+vxM6k6oRSHVwJXr3Oy8ZpCNUJNYIDIYgK1AMsFVKsONCeeVXSgJk7Y08FTrWA iA0AT8GwhxKQG/+b2KElJWMiC7kHIBANpiJlNLyRM1bDcROLideHgki/V5BsFGYhldei dLfg8wswxwhDzKBZu9wAGVCHSL81rzqFqwU0QfNbvw3d9OKPqvQWF3BkCvQDW+dyeuSh yiSy+cbks/hvdd8CPM6hXenTJqxHoKLjeA5yunkUiPruWS+V5aBNkaPvnhnHHitc+3NK 4z8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:date:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=jj9glYe0gvbVcAodw3qv6Kp672I6hibQ7u2mjdDL0BQ=; b=bq7Bb2l8ionPii3MKw0d90rn5xK0P1pU/DhkzfbgQ5eC0fsZF2P9DV4nV91HStN2JH 0N4lZRhbuY8f6mOiAQ/6lCiAcMgium2r48NwPKTiAB84DMJNuNufgacRKyEQL5YWpNjl B6vRCEqKU3AnsBjcE4Eyu5bWt5u0ubUhYTQQusdRWbRGFggF1HsGfR0t+Nw0YhAJwNJv QC+JDnJcJzVkfTZoGUvqwWpYrzZ07SA/bB+MicExLVfaGOZY0PgLG25i1aJaD4ZDWg+c 3scGWMLIsuUeVU+aNyLRJGR+QqUr9gSHFYtNsgP+eNcaRxoAd3A8Uxj99MgZPpbQPKuY E3fA== X-Gm-Message-State: AOAM5322byL5iL6/nAV2tg+Mcg+9sPWnD5E/nkM+94SBzdpEwFq3BLZc Vlj90ZjV21Zj74FTKnDqips= X-Received: by 2002:a05:6e02:4c8:: with SMTP id f8mr2034088ils.159.1603204396133; Tue, 20 Oct 2020 07:33:16 -0700 (PDT) Received: from rani.riverdale.lan ([2001:470:1f07:5f3::b55f]) by smtp.gmail.com with ESMTPSA id d14sm1820275ila.42.2020.10.20.07.33.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 20 Oct 2020 07:33:15 -0700 (PDT) Sender: Arvind Sankar From: Arvind Sankar X-Google-Original-From: Arvind Sankar Date: Tue, 20 Oct 2020 10:33:12 -0400 To: Joerg Roedel Cc: Arvind Sankar , Joerg Roedel , x86@kernel.org, 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: <20201020143312.GE2996696@rani.riverdale.lan> References: <20201019151121.826-1-joro@8bytes.org> <20201019151121.826-4-joro@8bytes.org> <20201019170008.GA2701355@rani.riverdale.lan> <20201019175447.GA2720155@rani.riverdale.lan> <20201019203935.GG3635@8bytes.org> <20201019213106.GB2815942@rani.riverdale.lan> <20201020085957.GF9328@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20201020085957.GF9328@suse.de> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Oct 20, 2020 at 10:59:57AM +0200, Joerg Roedel wrote: > On Mon, Oct 19, 2020 at 05:31:06PM -0400, Arvind Sankar wrote: > > Is it possible to take advantage of this to make the check independent > > of the original page tables? i.e. switch to the new pagetables, then > > write into .data or .bss the opcodes for a function that does > > movabs $imm64, %rax > > jmp *%rdi // avoid using stack for the return > > filling in the imm64 with the RDRAND value, and then try to execute it. > > If the C-bit value is wrong, this will probably crash, and at any rate > > shouldn't return with the correct value in %rax. > > That could work, but is not reliable. When the C bit is wrong the CPU > would essentially execute random data, which could also be a valid > instruction stream. A crash is not guaranteed. > That doesn't feel like a big loss: if a malicious hypervisor wanted to induce completely random code execution, it can do that anyway by just messing with the guest-to-host translation, no? We would need to avoid calling this in the secondary cpu startup, I guess. I was hoping to be able to clean up the identity mapping in __startup_64(), which currently maps the entire kernel using wraparound entries, to just map the head page of the kernel, since AFAICT nothing else is actually used from the identity mapping after switching to the new page tables. But we'd need to keep it to support this check.