Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp4675403iob; Sun, 8 May 2022 21:33:56 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyNXUirKiMqvYHzFCAD9Dk8iXeC6B37N5G8PI3/fKAQ0d25OcgkVgv/VfsVc/wHhuWqbo2Y X-Received: by 2002:a17:902:f684:b0:15e:8c4a:c54b with SMTP id l4-20020a170902f68400b0015e8c4ac54bmr14474723plg.21.1652070836587; Sun, 08 May 2022 21:33:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1652070836; cv=none; d=google.com; s=arc-20160816; b=KEjJxqROi6djoBetSSg6vFqG/Cb4e37J9QJUHsN1ZXe9FLAwpY+z9s1QX5QK0hpd6j 0RW0X4UcuPlSPuuDO05jh82XKfpgzgzilNkgIGJdL7e3j5DOC3Z5lzCmNzFAtblDOg+/ 3+zxYVNgQnrIoAPhfLR1Qd1iVboGP9h3r2by7fjMdDmqzr2kzJs1hqkW82F/5jFbuCIp 0RS5b8lRJzgZMfuOE/6DuM/nSiPjL6wFu9KcJhHDCrkYWJSyxzxUsL7BQKGkNVVEa7M3 qYISjhgmMsNucSURNCiLJ4AWQCzyxGXq9v4knJiHcnOglObJufcifYvpKx0jxY3mohth WJ9g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=H6CtP5sYlfUxxkJJRGAUm1PweT2FU9yktqMMlVO+rwI=; b=WdfYbTB2ce3uDnFOSP+aZF94vf4XlEULZaA+IBp/2MjpHoTnY0DjlaCqmVugX/m5rn pkrko3deJQAQTDj9GfwnYUb91vEetjELNurJlwoOhXKbc9cvwV3tJ2mPov6wY+t0sdC2 6a+K62LNG75tnZXa77KJwfsp/oYT9F0qwteOLphvcg7ZV/R3ec/5rls4x43T+WHfi6FI L38HTkIfhxSFb7Jq+zGY1HRyFl0hdz/uUdBQAbfrMa1/Rm+iXGVDuvF6cCCqG1i23+Ed f9VH+h5gwyiL47iLhmGGoUuqAOYmqOLTlUrayxoUzWWU+u4bXuQWSDHji97ih0hF6b9M dkxQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=Nt6KVKoA; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id w9-20020a170902d70900b0015e05374e86si9897870ply.443.2022.05.08.21.33.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 08 May 2022 21:33:56 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=Nt6KVKoA; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 3D4909156F; Sun, 8 May 2022 21:31:20 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1390596AbiEFSTj (ORCPT + 99 others); Fri, 6 May 2022 14:19:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38594 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1390808AbiEFSSO (ORCPT ); Fri, 6 May 2022 14:18:14 -0400 Received: from mga06.intel.com (mga06b.intel.com [134.134.136.31]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 363A36E8FE; Fri, 6 May 2022 11:14:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1651860844; x=1683396844; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=WizXc0R3BJTlovfE/8nWaCi8wLxJyfq2X70P9CYgneY=; b=Nt6KVKoAJx/UyC2TCKY/WmsNmcFLkdYXPB973USQLk654sxB7knmaLqN H/22pgspLeiRiWhbku69vm+A3oCcACkS5U/pGARvx6r32aH3jp5a1nlOj M/AJ6k21303jzbIAA/Zgpd8Xh65SCogjGcPb90ZdO3YXa/+5u1OwHX9yK GDQRHB5ntaD3TurVb2nzZgU0hXSZDcE3EmDhEi2zsFyghu8xzfU6eK6ig CZV+Jsr323QVAc7dEjhXp6xVwMmpLCsRmCM/KTOQ+h+OTzXNLlKjgPkU6 oIrxttoKSGGUX+tu4Uv1IDK/+4fXDW8KEIPSyeu626wHO/sKGmii4L5lj g==; X-IronPort-AV: E=McAfee;i="6400,9594,10339"; a="329084903" X-IronPort-AV: E=Sophos;i="5.91,205,1647327600"; d="scan'208";a="329084903" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 May 2022 11:14:03 -0700 X-IronPort-AV: E=Sophos;i="5.91,205,1647327600"; d="scan'208";a="695293311" Received: from hgadiraj-mobl2.amr.corp.intel.com (HELO [10.212.44.56]) ([10.212.44.56]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 May 2022 11:14:01 -0700 Message-ID: <6abea873-52a2-f506-b21b-4b567bee1874@intel.com> Date: Fri, 6 May 2022 11:14:00 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: [PATCH v8 0/8] x86: Show in sysfs if a memory node is able to do encryption Content-Language: en-US To: Boris Petkov , Dan Williams Cc: Martin Fernandez , Linux Kernel Mailing List , linux-efi , Linux MM , platform-driver-x86@vger.kernel.org, "Rafael J. Wysocki" , Thomas Gleixner , X86 ML , "Schofield, Alison" , Dave Hansen , Ingo Molnar , Andy Shevchenko , Greg KH , Mike Rapoport , Andrew Morton , Ard Biesheuvel , daniel.gutson@eclypsium.com, "H. Peter Anvin" , alex.bazhaniuk@eclypsium.com, hughsient@gmail.com, Kees Cook , Darren Hart , Ben Widawsky , "Huang, Kai" References: <20220429201717.1946178-1-martin.fernandez@eclypsium.com> <6d90c832-af4a-7ed6-4f72-dae08bb69c37@intel.com> <47140A56-D3F8-4292-B355-5F92E3BA9F67@alien8.de> From: Dave Hansen In-Reply-To: <47140A56-D3F8-4292-B355-5F92E3BA9F67@alien8.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,RDNS_NONE,SPF_HELO_NONE, T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 5/6/22 10:55, Boris Petkov wrote: > So here's the deal: we can say in the kernel that memory encryption > is enabled and active. But then all those different devices and so > on, can or cannot support encryption. IO devices do not support > encryption either, afaict. At least on MKTME platforms, if a device does DMA to a physical address with the KeyID bits set, it gets memory encryption. That's because all the encryption magic is done in the memory controller itself. The CPU's memory controller doesn't actually care if the access comes from a device or a CPU as long as the right physical bits are set. The reason we're talking about this in terms of CXL devices is that CXL devices have their *OWN* memory controllers. Those memory controllers might or might not support encryption. > But that is not the question - they don't wanna say in fwupd whether > every transaction was encrypted or not - they wanna say that > encryption is active. And that we can give them now. The reason we went down this per-node thing instead of something system-wide is EFI_MEMORY_CPU_CRYPTO. It's in the standard because EFI systems are not expected to have uniform crypto capabilities across the entire memory map. Some memory will be capable of CPU crypto and some not. As an example, if I were to build a system today with TDX and NVDIMMs, I'd probably mark the RAM as EFI_MEMORY_CPU_CRYPTO=1 and the NVDIMMs as EFI_MEMORY_CPU_CRYPTO=0. I think you're saying that current AMD SEV systems have no need for EFI_MEMORY_CPU_CRYPTO since their encryption capabilities *ARE* uniform. I'm not challenging that at all. This interface is total overkill for systems with guaranteed uniform encryption capabilities. But, this interface will *work* both for the uniform and non-uniform systems alike.