Received: by 2002:ac0:bc90:0:0:0:0:0 with SMTP id a16csp3786766img; Mon, 25 Mar 2019 18:29:02 -0700 (PDT) X-Google-Smtp-Source: APXvYqxSZ8zFlFDTsP+IxSa7yB6F5Wxv8S8JR0rzNj7sr8AUImitnQuPXCDOGlpTychZGN6iL9t2 X-Received: by 2002:a17:902:b10c:: with SMTP id q12mr10836953plr.254.1553563742818; Mon, 25 Mar 2019 18:29:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1553563742; cv=none; d=google.com; s=arc-20160816; b=QrYp4N+m9yxxrwrJ6U22aTd6DvX0tk8/S0ncyuzIz/fcDS7cNEu2lgs+Pn56celbdg Rz+/TMJQoDHwFnpj7lTwORAkiNDQCR2ph80PPhDwoq/LXhWqLZWCZ1WymO0d5mzgbBPZ bDZdjld4nMMnG3F2QlITAwaK0SqjbUgh2KWJv0bAUYM/g/joocVMs1YnwilCrSehcIOI WOiKc4SyvA/jUTdcyQZnpTRQtzCUzOHY0MDLhftWLhEZ4/CmsHtwmuvg5LYLpxKPlv20 +P2+2PemW6rdF7IcPLqyC0U4xKMZ+R6rm/hELy2tPh8LY8McC5y4xuRdspTJUXCLJ5xR 4xPA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=HVRh6NG7KipRUNc45xlD9kgbVmmgq6/fy3rYE48s+1U=; b=b93dzSonjfLGIs5rXBc5P6ylM4KQXW4KM/E4liKKqCHbScy7kCvWbnIACR/uZ6Pxxx lf7eG3Jf5eSB3UL6J+z889u27HNue1TJ3zhFAb9ZthbZHGk+MIDOygzjPgl7zobuwrJL xFAAqaPBrWVaN3LfXF5n02GWQxwSO2krkFGT3WGharFxRlOEryeM3knXS0M/w+8Sqa9q W+/dBvZYiNtQo/6aIF6ZmJZlzmUhdEX8H8yeuvACm4iT4LJaJPMqy3eqqeH7lvkX2TAL YWTVa+Tg2ZmZE8gFqzy9fSaDAHhr4cq7+vGrBh8OquqxFW/0rXQPxzl3SOLaBGaMS199 d8xA== 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 u9si14573496pgp.269.2019.03.25.18.28.47; Mon, 25 Mar 2019 18:29:02 -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 S1730559AbfCZB1y (ORCPT + 99 others); Mon, 25 Mar 2019 21:27:54 -0400 Received: from mx1.redhat.com ([209.132.183.28]:41706 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727427AbfCZB1y (ORCPT ); Mon, 25 Mar 2019 21:27:54 -0400 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id BDE4583F40; Tue, 26 Mar 2019 01:27:53 +0000 (UTC) Received: from localhost.localdomain (ovpn-12-53.pek2.redhat.com [10.72.12.53]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B2FC73842; Tue, 26 Mar 2019 01:27:41 +0000 (UTC) Subject: Re: [PATCH 1/3] kexec: Do not map the kexec area as decrypted when SEV is active To: Borislav Petkov , "Singh, Brijesh" , "Lendacky, Thomas" Cc: "linux-kernel@vger.kernel.org" , "kexec@lists.infradead.org" , "tglx@linutronix.de" , "mingo@redhat.com" , "x86@kernel.org" , "hpa@zytor.com" , "akpm@linux-foundation.org" , "dyoung@redhat.com" , "bhe@redhat.com" References: <20190315103203.13128-1-lijiang@redhat.com> <20190315103203.13128-2-lijiang@redhat.com> <20190324150034.GH23289@zn.tnic> <7b115829-40d9-e55e-dee3-ec8e4766971f@redhat.com> <20190325063742.GA12016@zn.tnic> <652b9166-f06e-c210-3c3f-c9e80a97db18@amd.com> <20190325173239.GO12016@zn.tnic> From: lijiang Message-ID: Date: Tue, 26 Mar 2019 09:27:38 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20190325173239.GO12016@zn.tnic> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Tue, 26 Mar 2019 01:27:53 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 在 2019年03月26日 01:32, Borislav Petkov 写道: > On Mon, Mar 25, 2019 at 05:17:55PM +0000, Singh, Brijesh wrote: >> By default all the memory regions are mapped encrypted. The >> set_memory_{encrypt,decrypt}() is a generic function which can be >> called explicitly to clear/set the encryption mask from the existing >> memory mapping. The mem_encrypt_active() returns true if either SEV or >> SME is active. So the __set_memory_enc_dec() uses the >> memory_encrypt_active() check to ensure that the function is no-op when >> SME/SEV are not active. >> >> Currently, the arch_kexec_post_alloc_pages() unconditionally clear the >> encryption mask from the kexec area. In case of SEV, we should not clear >> the encryption mask. > > Brijesh, I know all that. > > Please read what I said here at the end: > > https://lkml.kernel.org/r/20190324150034.GH23289@zn.tnic > > With this change, the code looks like this: > > + if (sme_active()) > + return set_memory_decrypted((unsigned long)vaddr, pages); > > now in __set_memory_enc_dec via set_memory_decrypted(): > > /* Nothing to do if memory encryption is not active */ > if (!mem_encrypt_active()) > return 0; > > > so you have: > > if (sme_active()) > > ... > > if (!mem_encrypt_active()) > > > now maybe this is all clear to you and Tom but I betcha others will get > confused. Probably something like "well, what should be active now, SME, > SEV or memory encryption in general"? > > I hope you're catching my drift. > > So if you want to *not* decrypt memory in the SEV case, then doing something > like this should make it a bit more clear: > > > if (sev_active()) > return; > > return set_memory_decrypted((unsigned long)vaddr, pages); > > along with a comment *why* we're checking here. It looks good to me. I will improve them next post. Thank you, everyone. Lianbo > > But actually, I'd prefer if you had separate wrappers which are called > for SME and for SEV. > > I'll let Tom chime in too. >