Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp1298046imm; Tue, 3 Jul 2018 08:45:28 -0700 (PDT) X-Google-Smtp-Source: ADUXVKJuu6YF9qqaEAoevn33WRHuzqsLv7WeWkhxZ7OGyjPOBsDLG1sDt29kTZFUiZ73903bPIuR X-Received: by 2002:a63:ab4c:: with SMTP id k12-v6mr25817528pgp.386.1530632728910; Tue, 03 Jul 2018 08:45:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1530632728; cv=none; d=google.com; s=arc-20160816; b=rGOr1XlSVoB5pPv88t2wyt/s35HNhn+nAVqUkp9fNH/GOCCq4UOUD2sygDNK/A6ONF ZD55u68dRvMNZyL85XNROxJtY9W6/N/8omd/Kvbm6ZBIbpZD2vz6wSW8EcH5TxO95ssx r0WbcLtOn68Qi5I9NzBYw1AsyUViie91o0QYKE1dAP+HfqIb9Cp6rmdt1L73oUzHcy0h nmdETSo0YwjGW9HmDY/tUqebigyaYFL+/m9+yOXtO22FgLQhKiKledAIXEZJ28WkIdPc KXYa1m2pNHiG8rzkTLzlqeUlqKCbeTZJRQ+yZNCDL9ybl5D1+BYXG3PWoYDjzlFw1EfT Euyw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date :arc-authentication-results; bh=4EijMi85v6qgIzlNMOjQzIZPu3pRI4oZw9aZzq7wVS0=; b=uxzOM7lGphUBZuJDU0UJ8wrncrMrzEqm9i+dxG4noLqhmydHQhtsG2U80YvnViBvYv NGzx0BMuG4Q8tfSjN8T6/2f5KijbKzVk+uF9IOzmZWLInkgVsDqKMNPghl3xpxBUqytt f7hbtn4gwgM3YtwrinHxqWab59sBF5P1MS8uMNTGmKcqJMcosV+NWVzDQ9kyiYvP0lVz +ehPZS8/jaD7ojVbCtNvJLN+IKyxk7MRnrsZ4GNbzfyiioCzFn8dP9/wo9ZT1LVeRnau OZGbmphCW2O2ZMQDV5+bogFg9ukf2P9hfupMJ7tEy/ze2thCH6zo7XVmt/U4qEoccy4j 3how== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t9-v6si1273225pgf.222.2018.07.03.08.45.14; Tue, 03 Jul 2018 08:45:28 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753473AbeGCPo2 (ORCPT + 99 others); Tue, 3 Jul 2018 11:44:28 -0400 Received: from mx2.suse.de ([195.135.220.15]:43690 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752905AbeGCPo0 (ORCPT ); Tue, 3 Jul 2018 11:44:26 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id D820EB00F; Tue, 3 Jul 2018 15:44:24 +0000 (UTC) Date: Tue, 3 Jul 2018 17:44:18 +0200 From: Borislav Petkov To: Ard Biesheuvel Cc: Brijesh Singh , the arch/x86 maintainers , linux-efi , Linux Kernel Mailing List , Tom Lendacky , Thomas Gleixner , KVM devel mailing list , Matt Fleming , Andy Lutomirski Subject: Re: [PATCH] x86/efi: Access EFI MMIO data as unencrypted when SEV is active Message-ID: <20180703154418.GC4643@zn.tnic> References: <1530624720-32004-1-git-send-email-brijesh.singh@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.9.5 (2018-04-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org (dropping stable@ as this is not how you send patches to stable). On Tue, Jul 03, 2018 at 05:37:18PM +0200, Ard Biesheuvel wrote: > On 3 July 2018 at 15:32, Brijesh Singh wrote: > > SEV guest fails to update the UEFI runtime variables stored in the > > flash. commit 1379edd59673 ("x86/efi: Access EFI data as encrypted > > when SEV is active") unconditionally maps all the UEFI runtime data > > as 'encrypted' (C=1). When SEV is active the UEFI runtime data marked > > as EFI_MEMORY_MAPPED_IO should be mapped as 'unencrypted' so that both > > guest and hypervisor can access the data. > > > > I'm uncomfortable having to carry these heuristics in the kernel. The > UEFI memory map should be the definitive source of information > regarding how the OS should map the regions it describes, and if we > need to guess the encryption status, we are likely to get it wrong at > least some of the times. I think the problem here is that IO memory can't be encrypted, at least at the moment. Thus this patch. I believe future versions will be able to handle encrypted IO but that's something Brijesh can correct me on. So it is not really about the UEFI spec but about what the hardware does/supports currently. And I don't think that change matters on anything else besides AMD with SEV enabled... Thx. -- Regards/Gruss, Boris. SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) --