Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp5446671ybi; Tue, 4 Jun 2019 06:51:49 -0700 (PDT) X-Google-Smtp-Source: APXvYqzjLN82GQJ6u5+gPAR6fNhWAjPZopjliUzqPdJ9cMUX2yQcBWt5/oHW/TsdZpRll/azrQxS X-Received: by 2002:a17:902:8c94:: with SMTP id t20mr35409780plo.141.1559656309103; Tue, 04 Jun 2019 06:51:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1559656309; cv=none; d=google.com; s=arc-20160816; b=Ef4uVuinSzvPriJT79ON9hsjfLvDx/6Y/ZFAdZRgKshN0jDEyUa0mpaLol81iF74ts tSqIxvDIHhz3E56UfbbCa/5FNy+KXU+hvhmb+cAEmeXXUhvB5tjAYBApDXKw+U/6mjDC AL0l8wIT8s/h6gMUhn8Rd97aXMSrXhnZ6+hYqaSeCU6tw9IPmao0IUh9fDqxwo8FIhxO 38l3kmswItVESk7KEFWnWWqZ9DMjn8kWkGY+6p0sp1+AHR9xWjZ4BXyaawDPmwrfqDyq FdwFcTgNCbgTg5wNnufKc+OlvYeQAv2it6gSyDARhv72iIgGP7ITKicik0qRneVWSlC2 LNww== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:content-disposition :mime-version:message-id:subject:cc:to:from:date; bh=2HAe4ApTcUsM/qC9vGS354dZIHyMQwOCNAFWM3yN7ns=; b=VJTjLnGfeipPIb3Snp6l7tSabW+PHbLH4iCcFEfZXhge7PcK/VKwpo/tcWWuyWOjU5 fTwYHreo+K6pYBn6bQg5mUQSUtjZrPhAeydJ33Ut7zV35/UnxSsxdMWIqjujEDig7JEF 5H52HwnO6gLthgqrro1dbyXVslpi8xfI4JNE+n0LgJ0lgwk3lhbU31Kluzs+FmfuBZWY /nHIYLNYA5Gxs3e9FmqNHbCodLb4cyWTocCSBUtcFn0aa82mM6wSlJi5GVXpt091KW1l byqtDdM0UaOn2J2fpjhoh1nkgjJcV3rVSgkStn67NN3rObXbBALuyGDDdWIz7Oqr2ZJJ Nzbw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 76si22345460pgc.16.2019.06.04.06.51.30; Tue, 04 Jun 2019 06:51:49 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727524AbfFDNuC (ORCPT + 99 others); Tue, 4 Jun 2019 09:50:02 -0400 Received: from mx1.redhat.com ([209.132.183.28]:51608 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727506AbfFDNuB (ORCPT ); Tue, 4 Jun 2019 09:50:01 -0400 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B4CC5307D932; Tue, 4 Jun 2019 13:49:56 +0000 (UTC) Received: from localhost (ovpn-12-57.pek2.redhat.com [10.72.12.57]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 24D955D9E5; Tue, 4 Jun 2019 13:49:54 +0000 (UTC) Date: Tue, 4 Jun 2019 21:49:52 +0800 From: Baoquan He To: Thomas.Lendacky@amd.com Cc: kexec@lists.infradead.org, x86@kernel.org, linux-kernel@vger.kernel.org Subject: The current SME implementation fails kexec/kdump kernel booting. Message-ID: <20190604134952.GC26891@MiWiFi-R3L-srv> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.10.1 (2018-07-13) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.48]); Tue, 04 Jun 2019 13:50:01 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Tom, Lianbo reported kdump kernel can't boot well with 'nokaslr' added, and have to enable KASLR in kdump kernel to make it boot successfully. This blocked his work on enabling sme for kexec/kdump. And on some machines SME kernel can't boot in 1st kernel. I checked code of SME implementation, and found out the root cause. The above failures are caused by SME code, sme_encrypt_kernel(). In sme_encrypt_kernel(), you get a 2M of encryption work area as intermediate buffer to encrypt kernel in-place. And the work area is just after _end of kernel. This happens to work in 1st kernel. But it will fail kexec/kdump kernel absolutely. Because we load realmode/kernel/initrd in kexec-tools from top to down. In kexec-tools, realmode is put just after kernel image. If KASLR enabled, kernel may be randomized to other position, then kdump kernel can boot. However, if nokaslr specified, the 2M intermediate encryption workarea will definitely stump into the following realmode, and fail kexec/kdump kernel booting. I have hacked kexec-tools code to put real mode area 4M away from the kernel image end, it works and confirm my finding. So the current SME in-place encryption way is not only a kexec/kdump issue, but also an issue in 1st kernel. Because KASLR could put kernel at the end of an available memory region, how to make sure the next 2M intermediate workarea must exist; if KASLR put kernel to be close to starting address of any cmdline/initrd/setup_data, how to make sure the gap between them must be larger than 2M. Thanks Baoquan