From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 90D76C4332F for ; Wed, 18 May 2022 18:29:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241405AbiERS3H (ORCPT ); Wed, 18 May 2022 14:29:07 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43728 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241389AbiERS3C (ORCPT ); Wed, 18 May 2022 14:29:02 -0400 Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C1024205241 for ; Wed, 18 May 2022 11:29:00 -0700 (PDT) Received: by mail-pg1-x52d.google.com with SMTP id a38so23767pgl.9 for ; Wed, 18 May 2022 11:29:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rs+hYjREIGQRrA6fYOwB+iDuVdssLJ9+QtiHFV7DjL0=; b=56li6rLC4mQzRo0A2kXqCOMihPnh37A1HauoHxo4CjJMMuRdOwMf25S0Gg0mhW4H1V 9oOovgGOyX26iKhdSLr17ZDHUilwvfRWItX4kYjWxDcZeJLKtWZdFg1s7NiWZdD+GyVM KJttKiC4l1M5erBf0kwMAuhlpCYSJef4Ht1zQqWzfQh9U259WzwAbZy7OglBSEw1Kkt5 I8zIKarbcikHCK0RFMumk20d6U4SinIwA/pHFrpQj3jVTbbDOPe4Z+fN1BJJD+DxEI+B O7cWYnGGR+LQ4+Smr495r3EMtIZ9/Hrn5EVFhO1s214IbW9ifIzL2RKvXS2XHrYOVgOA InyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rs+hYjREIGQRrA6fYOwB+iDuVdssLJ9+QtiHFV7DjL0=; b=Oj3XBD01MWaL4w5+awgpQA0uIveY52GpqFJ640Y9qs8Div6lBtiZpPXuJMJHajvIL3 IX2PHu6i1hivRdHiP/ruiGH7TlCELSnDA2GEhCYfw7wID24a6AVL9gOv5Y76WNlXgh91 drSUobGdXo8QDvF5byr94TcdC30lYi0ttVjZTaIlSrSEGnf4cxs2rWpn4TLyvuSHhZTr jRXt5o0pbQWrHK1ZmQ2jj7kQCTGydTcm6RrNwTBJC9e5g0TClEW19GiHn9rRJ4bza3YG v8ia8MZjF5UGENEZVaEOWo5PJdOAcBTNnpex9/0eu9rxjRCH5Ys4rtDNvmN3I5zhmY2P JUVw== X-Gm-Message-State: AOAM532EgD6KZpITCXy8rK3IYIgw9N31Qq8IL2tgzQtFXE3jT/yFJ8uR w4yPGWruk3rIRdzY3PsKkRrjgAtj7npzwYHARbNXBw== X-Google-Smtp-Source: ABdhPJwMwJen2kHUljMxLGhfJo+EhmxX/T4W59DWfSThgOD6IYw6SPZuTRmwpc9boSVZhrVVAKPtxD2J9ln9cKQkELQ= X-Received: by 2002:a63:e648:0:b0:3f2:7ade:8f86 with SMTP id p8-20020a63e648000000b003f27ade8f86mr670271pgj.40.1652898540353; Wed, 18 May 2022 11:29:00 -0700 (PDT) MIME-Version: 1.0 References: <6d90c832-af4a-7ed6-4f72-dae08bb69c37@intel.com> <47140A56-D3F8-4292-B355-5F92E3BA9F67@alien8.de> <6abea873-52a2-f506-b21b-4b567bee1874@intel.com> <4bc56567-e2ce-40ec-19ab-349c8de8d969@intel.com> In-Reply-To: From: Dan Williams Date: Wed, 18 May 2022 11:28:49 -0700 Message-ID: Subject: Re: [PATCH v8 0/8] x86: Show in sysfs if a memory node is able to do encryption To: Borislav Petkov Cc: Richard Hughes , Dave Hansen , Martin Fernandez , Linux Kernel Mailing List , linux-efi , platform-driver-x86@vger.kernel.org, Linux MM , "H. Peter Anvin" , daniel.gutson@eclypsium.com, Darren Hart , Andy Shevchenko , Kees Cook , Andrew Morton , Ard Biesheuvel , Ingo Molnar , Thomas Gleixner , Dave Hansen , "Rafael J. Wysocki" , X86 ML , "Schofield, Alison" , alex.bazhaniuk@eclypsium.com, Greg KH , Mike Rapoport , Ben Widawsky , "Huang, Kai" Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 18, 2022 at 12:53 AM Borislav Petkov wrote: > > On Mon, May 16, 2022 at 09:39:06AM +0100, Richard Hughes wrote: > > This is still something consumers need; at the moment users have no > > idea if data is *actually* being encrypted. > > As it was already pointed out - that's in /proc/cpuinfo. For TME you still need to compare it against the EFI memory map as there are exclusion ranges for things like persistent memory. Given that persistent memory can be forced into volatile "System RAM" operation by various command line options and driver overrides, you need to at least trim the assumptions of what is encrypted to the default "conventional memory" conveyed by platform firmware / BIOS.