Received: by 2002:ab2:7855:0:b0:1f9:5764:f03e with SMTP id m21csp732180lqp; Wed, 22 May 2024 19:52:52 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCVCLzu7hxIcr/XvhNRjzzv+W427S9hDbV+1OzFaaA1zZvGM0dFj+u00DkluZA7eE48bW6QOlpnYNi2EevHLJuy8WFgmhKLV5+sjQPov4A== X-Google-Smtp-Source: AGHT+IEVzixDy06N5BqD922qHnrwfPfyAP2Q4gkuwIroJzHCdajV/GeuPas3uNBKIYeqcW6pw/tF X-Received: by 2002:a9d:3e0f:0:b0:6f1:27df:44e1 with SMTP id 46e09a7af769-6f669aff396mr3853583a34.31.1716432771956; Wed, 22 May 2024 19:52:51 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1716432771; cv=pass; d=google.com; s=arc-20160816; b=eW1hLUrQxn5IO6RcnPN0lvaDFYp/xoEoKTdiAFApsT+fXNFc4N9UX9B5szOdrQj5Ni UylRZ/EIl+r8cNrjXdDio/B9t9XrkgEk2TfRYQdTGaVnAmEZdoV1TJIHnZyw3kHgl+oH qg2MS3OiqRSz3beQGd+aaw8VhNpNzA5Xpdgwh/iBR3Uu6tCsB9mvgn8cLmgNtOQT4K+J 2yUp6ToAmTYxwWriQgaoRW3wJiRt+/4SVDexCZi/XSA8ErW4TY4jDBzKhZ6Ed4UxM0VE 2TVY1X3vygQoWanBGR54yD7aZzGb37safwL4I0PtlL5ZKjVrDBicpezP2jAQsAipJ5qq /ywg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:list-unsubscribe:list-subscribe:list-id:precedence :dkim-signature; bh=tWbBNmbHIEsZsY7vbmRzxEnY1vtC+xzevrdRnLUowJI=; fh=PvNjE/PHEKTUvrfUgcTc9uNth4VC8kgrGaGBYCemESw=; b=jzbkHlmAQO2WyA7MMWYoeX9CNoW18++4WBtOoXxhD84Js2seQcRpT+QYQTL69dbBIK DSILRwsjzlE+LkR3Cz9QQ+OeB5HrP1vVMQWZAojzWaeLbnzKeZV0q6OxgCrdM41ylldu CC3eGIm+RibkGqI6Z3f5on5cPPcaXfX5oByCXBT/fLRycmoCZM9oFWzRWRINNOl3vuTz sd10pZYp7o9WoCKizQf5/aNF85hxXOVPMylP8PkPyCnLS0R9aC9UDckTRnJwbCbpkhZo sL4NyORvp/+Lf/i6BVOQWSMFHiyqSuiXglq/aavyqDFOAm9gnWI984A9tiOBLodCPLQX ASMQ==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=ZT4a9IjK; arc=pass (i=1 spf=pass spfdomain=redhat.com dkim=pass dkdomain=redhat.com dmarc=pass fromdomain=redhat.com); spf=pass (google.com: domain of linux-kernel+bounces-186928-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-186928-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id 41be03b00d2f7-63409e837acsi709032a12.102.2024.05.22.19.52.51 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 22 May 2024 19:52:51 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-186928-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=ZT4a9IjK; arc=pass (i=1 spf=pass spfdomain=redhat.com dkim=pass dkdomain=redhat.com dmarc=pass fromdomain=redhat.com); spf=pass (google.com: domain of linux-kernel+bounces-186928-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-186928-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 62EAE282B5D for ; Thu, 23 May 2024 02:52:51 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 8982A13A41C; Thu, 23 May 2024 02:52:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="ZT4a9IjK" Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4BCC341C6C for ; Thu, 23 May 2024 02:52:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1716432765; cv=none; b=BukjezRZpuMu9eW8GBJ789VYaNpJgZ6y7kuVONACBiERO0JO4Klv2fpsPSU/x3nUqxhjTAQAQyFsAtUyn6XlGekb0JZ1DxEUUb9Ud+9Mm1tKLDVdE4kQoabInDU5PjiggUrP9V7jgB1nQzK6C/gYQOgNpl9VqoOElj7fC/ljYJE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1716432765; c=relaxed/simple; bh=vR4+HrpPnSv3yvS4mfdFSTip8mI9qycDvxOpHK+uwzY=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=n7a4TQ7fWwsBThiZZGe59U27Db4N10kVBgvd/ZiG+rqmJPE6AnOeiB9Nh7ds2U5IUx8jC2h97NZr5wzhj79dw7BT7jIM8JhxSxIsr0HqA8Z8LCG6iSo9KflenMHKyvU6zoKb8oACe2eYs+OCLfD8VxsvvyzrW3poa7MY4QYO4mI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=ZT4a9IjK; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1716432762; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=tWbBNmbHIEsZsY7vbmRzxEnY1vtC+xzevrdRnLUowJI=; b=ZT4a9IjKfUGL2skwqUj6nHZwQJnvEEeXPyx3Nviha3mhqyajjRPSWUlKymKJuwPXl2c/Qb EPvILrEqnaA4rPJ30Xb9Ex1mCN9ArWzWsW7Z3TYfJqTtD+VczfkF8POnp5hsp0GrjO5v2G QD4ALGKdBuDzoKRP5mfP9YZ09/yyvms= Received: from mail-io1-f72.google.com (mail-io1-f72.google.com [209.85.166.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-367-0Y3kWN3yNoCqkw17SSSymw-1; Wed, 22 May 2024 22:52:40 -0400 X-MC-Unique: 0Y3kWN3yNoCqkw17SSSymw-1 Received: by mail-io1-f72.google.com with SMTP id ca18e2360f4ac-7da357c99ceso10613539f.1 for ; Wed, 22 May 2024 19:52:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716432760; x=1717037560; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=tWbBNmbHIEsZsY7vbmRzxEnY1vtC+xzevrdRnLUowJI=; b=gLacwOiJpD8nu/PzG4HcmfKCr5Zz7ZZu8sfpPprxoMsN3a2wGBJcHBDgh75QQP/3tT j1tnG3vOgysgi1hHjVVD/jLt9Ekk994peZuhg09jrNIlNbR6kSE8SDPUqx0D8LGyzUkW 6uTvUYpAhvMv0mzDyXUbCxvMswk1rwZe5lOQplYirkaCl+V8wuEFrjY0F3Q9qYLZQLeX NjP86+0Z6GBvMAxdT3lLHCyS9PkeWAEg62jCR+QMTSHYf2CWZwvvBxVmVG5br9UaSdrG dT6+xaCTVpnyFBcuf18oWjUmZhY5CUVI7qJcqTUIGyLGhioHBneYrz9e6HLFkWn1rrkC AFAg== X-Forwarded-Encrypted: i=1; AJvYcCUanhrjPMUDNPS8ORpnMGkG95mCjWBzMOHYPqLN8AdTbuT9V1qGXrZ9fvqUlI9GeHYnH6Ww0tyL0NeLY4euXpzu2rbokqeXalFHQP89 X-Gm-Message-State: AOJu0YwGtvmlAooAjvnW3Fo5Guz/BoVwIi1/IoWnAgxrmTpR8M3VDbA8 hej9gJec6NxY0JreFr2yhZR+f50Mi3OM0JWjHWI3Ki8Jfk2AyVHMTjybFxaTKBUv/+HM8Uhj3/+ nEb9J67MhPBdH8FKygrfV4uBxMbF4w7fjEhOxMMlL/CZa4fYVCjwVhyA/7RRRmLjnIxyJErWoPT +8DfqlFDjI8RXMVLc3dHeJNrfU8uE4odaVVHB5 X-Received: by 2002:a05:6e02:1d0b:b0:36d:96ab:f4a with SMTP id e9e14a558f8ab-371f91127a8mr41001615ab.1.1716432759661; Wed, 22 May 2024 19:52:39 -0700 (PDT) X-Received: by 2002:a05:6e02:1d0b:b0:36d:96ab:f4a with SMTP id e9e14a558f8ab-371f91127a8mr41001505ab.1.1716432759314; Wed, 22 May 2024 19:52:39 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20240520183633.1457687-1-steve.wahl@hpe.com> In-Reply-To: <20240520183633.1457687-1-steve.wahl@hpe.com> From: Dave Young Date: Thu, 23 May 2024 10:52:59 +0800 Message-ID: Subject: Re: [PATCH 0/3] Resolve problems with kexec identity mapping To: Steve Wahl Cc: Dave Hansen , Andy Lutomirski , Peter Zijlstra , Thomas Gleixner , Ingo Molnar , Borislav Petkov , x86@kernel.org, "H. Peter Anvin" , linux-kernel@vger.kernel.org, Pavin Joseph , Eric Hagberg , Simon Horman , Eric Biederman , Sarah Brofeldt , Russ Anderson , Dimitri Sivanich , Hou Wenlong , Andrew Morton , Baoquan He , Yuntao Wang , Bjorn Helgaas , Joerg Roedel , Michael Roth , Tao Liu Content-Type: text/plain; charset="UTF-8" Add Tao in the cc list. On Tue, 21 May 2024 at 02:37, Steve Wahl wrote: > > Although there was a previous fix to avoid early kernel access to the > EFI config table on Intel systems, the problem can still exist on AMD > systems that support SEV (Secure Encrypted Virtualization). The > command line option "nogbpages" brings this bug to the surface. And > this is what caused the regression with my earlier patch that > attempted to reduce the use of gbpages. This patch series fixes that > problem and restores my earlier patch. > > The following 2 commits caused the EFI config table, and the CC_BLOB > entry in that table, to be accessed when enabling SEV at kernel > startup. > > commit ec1c66af3a30 ("x86/compressed/64: Detect/setup SEV/SME features > earlier during boot") > commit c01fce9cef84 ("x86/compressed: Add SEV-SNP feature > detection/setup") > > These accesses happen before the new kernel establishes its own > identity map, and before establishing a routine to handle page faults. > But the areas referenced are not explicitly added to the kexec > identity map. > > This goes unnoticed when these areas happen to be placed close enough > to others areas that are explicitly added to the identity map, but > that is not always the case. > > Under certain conditions, for example Intel Atom processors that don't > support 1GB pages, it was found that these areas don't end up mapped, > and the SEV initialization code causes an unrecoverable page fault, > and the kexec fails. > > Tau Liu had offered a patch to put the config table into the kexec > identity map to avoid this problem: > > https://lore.kernel.org/all/20230601072043.24439-1-ltao@redhat.com/ > > But the community chose instead to avoid referencing this memory on > non-AMD systems where the problem was reported. > > commit bee6cf1a80b5 ("x86/sev: Do not try to parse for the CC blob > on non-AMD hardware") > > I later wanted to make a different change to kexec identity map > creation, and had this patch accepted: > > commit d794734c9bbf ("x86/mm/ident_map: Use gbpages only where full GB page should be mapped.") > > but it quickly needed to be reverted because of problems on AMD systems. > > The reported regression problems on AMD systems were due to the above > mentioned references to the EFI config table. In fact, on the same > systems, the "nogbpages" command line option breaks kexec as well. > > So I resubmit Tau Liu's original patch that maps the EFI config > table, add an additional patch by me that ensures that the CC blob is > also mapped (if present), and also resubmit my earlier patch to use > gpbages only when a full GB of space is requested to be mapped. > > I do not advocate for removing the earlier, non-AMD fix. With kexec, > two different kernel versions can be in play, and the earlier fix > still covers non-AMD systems when the kexec'd-from kernel doesn't have > these patches applied. > > All three of the people who reported regression with my earlier patch > have retested with this patch series and found it to work where my > single patch previously did not. With current kernels, all fail to > kexec when "nogbpages" is on the command line, but all succeed with > "nogbpages" after the series is applied. > > Tao Liu (1): > x86/kexec: Add EFI config table identity mapping for kexec kernel > > Steve Wahl (2): > x86/kexec: Add EFI Confidential Computing blob to kexec identity > mapping. > x86/mm/ident_map: Use gbpages only where full GB page should be > mapped. > > arch/x86/kernel/machine_kexec_64.c | 82 ++++++++++++++++++++++++++++-- > arch/x86/mm/ident_map.c | 23 +++++++-- > 2 files changed, 95 insertions(+), 10 deletions(-) > > -- > 2.26.2 >