From patchwork Fri Apr 29 20:17:10 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Martin Fernandez X-Patchwork-Id: 568828 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 DBDC1C433FE for ; Fri, 29 Apr 2022 20:17:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1380339AbiD2UVF (ORCPT ); Fri, 29 Apr 2022 16:21:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49552 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1380415AbiD2UVD (ORCPT ); Fri, 29 Apr 2022 16:21:03 -0400 Received: from mail-oi1-x230.google.com (mail-oi1-x230.google.com [IPv6:2607:f8b0:4864:20::230]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E0710A0BE7 for ; Fri, 29 Apr 2022 13:17:43 -0700 (PDT) Received: by mail-oi1-x230.google.com with SMTP id e4so9682991oif.2 for ; Fri, 29 Apr 2022 13:17:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eclypsium.com; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=erdqpZYLja6xDuoUNWXMJOEwQp9qkWbhvYqoJ4co3Os=; b=Q8UaonxznDmVc5gYov0m3G8lVeCJ9Wb++XO9fsv/gUqnPbStpjqIwYe0Rw241Jt1og 1wa4l4d7Jn89Q6/jKFGGjyxze+q8g5RO76SUkMpqYIydbKVQsVVVkKPc4RTvRQrGXHMg 6JTEB1ypvif9eRNj71NjI2Evpbuj5TuoHjCM2lZRZVLUM639ACMhnI9YvSOUfv0Q7u2R NOE7GpoeOT13Bxh590c+Vl6CGhR853U0Cgerj84916BoD9SDlzZ/JWwExnQbAUqEej6c z6Hs34KYKYNJDv/dkHUIU5fef1Ko3XrI07IFdNKGHp6BSyhh3MIfVHVkDqFE5bZN8rGH nuJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=erdqpZYLja6xDuoUNWXMJOEwQp9qkWbhvYqoJ4co3Os=; b=ctr9Let+cS7VbBbtKIHn1llZxpN0ABJJTeIxIakj4qilDknz/G0VgjaBmZXK18ORq7 XxusG99ZWkrTfaxinqetIGjOcjzK6aqsAK2RvahkyZo6zVo7I4sXMICEAqMFB4Rosw3w Mh/S0YlVUFJoGQvs2gpNfZCa6LyuAN9of8nlIawZlEiTlU/1mWsLbYoEltywFsAy172r FxBR1Dz8NWt9HQm7+mV8E5IAnnrDJ1OH6xvW8yWze5WpYQ4V5oGbQkODiW2tbcJ6I0a0 j8a900y6HTITYhLr8gB06qbEzE9P73+QhgzRfMUE0VlH9jJ28CwbADCNnFuCV1+tP4Cz by9w== X-Gm-Message-State: AOAM531QCtaXx+l3weySSF0TMAEY+i4f3ve3sYgMT0A/UPt1oeYw9Cfc YvA8qSXwOumrpX9LnoODc2ag+Q== X-Google-Smtp-Source: ABdhPJy1S2Ga4gCTYWLTSbLa/82ZQQmEvsYqOntWhuKnf1oxCmz0Cqnw2boboebtXSxhyQGp+cBYEw== X-Received: by 2002:a05:6808:1115:b0:2ec:e103:99c8 with SMTP id e21-20020a056808111500b002ece10399c8mr533592oih.194.1651263463240; Fri, 29 Apr 2022 13:17:43 -0700 (PDT) Received: from localhost ([181.97.174.128]) by smtp.gmail.com with ESMTPSA id r2-20020a05687002c200b000e99b1909d4sm2650005oaf.25.2022.04.29.13.17.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 29 Apr 2022 13:17:41 -0700 (PDT) From: Martin Fernandez To: linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org, platform-driver-x86@vger.kernel.org, linux-mm@kvack.org Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, ardb@kernel.org, dvhart@infradead.org, andy@infradead.org, gregkh@linuxfoundation.org, rafael@kernel.org, rppt@kernel.org, akpm@linux-foundation.org, daniel.gutson@eclypsium.com, hughsient@gmail.com, alex.bazhaniuk@eclypsium.com, alison.schofield@intel.com, keescook@chromium.org, Martin Fernandez Subject: [PATCH v8 1/8] mm/memblock: Tag memblocks with crypto capabilities Date: Fri, 29 Apr 2022 17:17:10 -0300 Message-Id: <20220429201717.1946178-2-martin.fernandez@eclypsium.com> X-Mailer: git-send-email 2.30.2 In-Reply-To: <20220429201717.1946178-1-martin.fernandez@eclypsium.com> References: <20220429201717.1946178-1-martin.fernandez@eclypsium.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-efi@vger.kernel.org Add the capability to mark regions of the memory memory_type able of hardware memory encryption. Also add the capability to query if all regions of a memory node are able to do hardware memory encryption to call it when initializing the nodes. Warn the user if a node has both encryptable and non-encryptable regions. Signed-off-by: Martin Fernandez --- include/linux/memblock.h | 5 ++++ mm/memblock.c | 62 ++++++++++++++++++++++++++++++++++++++++ 2 files changed, 67 insertions(+) diff --git a/include/linux/memblock.h b/include/linux/memblock.h index 50ad19662a32..00c4f1a20335 100644 --- a/include/linux/memblock.h +++ b/include/linux/memblock.h @@ -40,6 +40,7 @@ extern unsigned long long max_possible_pfn; * via a driver, and never indicated in the firmware-provided memory map as * system RAM. This corresponds to IORESOURCE_SYSRAM_DRIVER_MANAGED in the * kernel resource tree. + * @MEMBLOCK_CRYPTO_CAPABLE: capable of hardware encryption */ enum memblock_flags { MEMBLOCK_NONE = 0x0, /* No special request */ @@ -47,6 +48,7 @@ enum memblock_flags { MEMBLOCK_MIRROR = 0x2, /* mirrored region */ MEMBLOCK_NOMAP = 0x4, /* don't add to kernel direct mapping */ MEMBLOCK_DRIVER_MANAGED = 0x8, /* always detected via a driver */ + MEMBLOCK_CRYPTO_CAPABLE = 0x10, /* capable of hardware encryption */ }; /** @@ -120,6 +122,9 @@ int memblock_physmem_add(phys_addr_t base, phys_addr_t size); void memblock_trim_memory(phys_addr_t align); bool memblock_overlaps_region(struct memblock_type *type, phys_addr_t base, phys_addr_t size); +bool memblock_node_is_crypto_capable(int nid); +int memblock_mark_crypto_capable(phys_addr_t base, phys_addr_t size); +int memblock_clear_crypto_capable(phys_addr_t base, phys_addr_t size); int memblock_mark_hotplug(phys_addr_t base, phys_addr_t size); int memblock_clear_hotplug(phys_addr_t base, phys_addr_t size); int memblock_mark_mirror(phys_addr_t base, phys_addr_t size); diff --git a/mm/memblock.c b/mm/memblock.c index e4f03a6e8e56..d6399835b155 100644 --- a/mm/memblock.c +++ b/mm/memblock.c @@ -191,6 +191,40 @@ bool __init_memblock memblock_overlaps_region(struct memblock_type *type, return i < type->cnt; } +/** + * memblock_node_is_crypto_capable - get if whole node is capable + * of encryption + * @nid: number of node + * + * Iterate over all memory memblock_type and find if all regions under + * node @nid are capable of hardware encryption. + * + * Return: + * true if every region in @nid is capable of encryption, false + * otherwise. + */ +bool __init_memblock memblock_node_is_crypto_capable(int nid) +{ + struct memblock_region *region; + int crypto_capables = 0; + int not_crypto_capables = 0; + + for_each_mem_region(region) { + if (memblock_get_region_node(region) == nid) { + if (region->flags & MEMBLOCK_CRYPTO_CAPABLE) + crypto_capables++; + else + not_crypto_capables++; + } + } + + if (crypto_capables > 0 && not_crypto_capables > 0) + pr_warn("Node %d has %d regions that are encryptable and %d regions that aren't", + nid, not_crypto_capables, crypto_capables); + + return crypto_capables > 0 && not_crypto_capables == 0; +} + /** * __memblock_find_range_bottom_up - find free area utility in bottom-up * @start: start of candidate range @@ -891,6 +925,34 @@ static int __init_memblock memblock_setclr_flag(phys_addr_t base, return 0; } +/** + * memblock_mark_crypto_capable - Mark memory regions capable of hardware + * encryption with flag MEMBLOCK_CRYPTO_CAPABLE. + * @base: the base phys addr of the region + * @size: the size of the region + * + * Return: 0 on success, -errno on failure. + */ +int __init_memblock memblock_mark_crypto_capable(phys_addr_t base, + phys_addr_t size) +{ + return memblock_setclr_flag(base, size, 1, MEMBLOCK_CRYPTO_CAPABLE); +} + +/** + * memblock_clear_crypto_capable - Clear flag MEMBLOCK_CRYPTO for a + * specified region. + * @base: the base phys addr of the region + * @size: the size of the region + * + * Return: 0 on success, -errno on failure. + */ +int __init_memblock memblock_clear_crypto_capable(phys_addr_t base, + phys_addr_t size) +{ + return memblock_setclr_flag(base, size, 0, MEMBLOCK_CRYPTO_CAPABLE); +} + /** * memblock_mark_hotplug - Mark hotpluggable memory with flag MEMBLOCK_HOTPLUG. * @base: the base phys addr of the region From patchwork Fri Apr 29 20:17:11 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Martin Fernandez X-Patchwork-Id: 567603 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 25817C433EF for ; Fri, 29 Apr 2022 20:17:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1380512AbiD2UVM (ORCPT ); Fri, 29 Apr 2022 16:21:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50522 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1380484AbiD2UVL (ORCPT ); Fri, 29 Apr 2022 16:21:11 -0400 Received: from mail-oa1-x2f.google.com (mail-oa1-x2f.google.com [IPv6:2001:4860:4864:20::2f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D2F4AA0BE7 for ; Fri, 29 Apr 2022 13:17:51 -0700 (PDT) Received: by mail-oa1-x2f.google.com with SMTP id 586e51a60fabf-e5ca5c580fso9219719fac.3 for ; Fri, 29 Apr 2022 13:17:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eclypsium.com; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=cuoU1kSVf8VEBS5kxyG+ti9eeLYydPT4J1CXt5LwLhU=; b=Ca5CpkEdAGoDq4Rv1TW6+hSfJvX+bFxVgDxtp2Me/AhtkYKBKy7HDq9kO20qbFkCU/ oD5DMChdyFmU3n3DgPNgqCCNm7kr+52q5L9Hs/atSrY+4iP2qvhY/q2YA44Z2lv4tRjd v+qrNTH6cIBZ9Su9FBIIHdnb4f7y2STK1hcq14DBBiSA+1dXsvH5vR9SgVQv5TpKV515 6JTZ+l5RXQFB1Sq+ZHqkQs2djzOBE2pbg+fG2kXx5gpAKt3GP7C7mx5AJDZr8JYHBth7 TYSaK6qQeMoDiSKDnXRZLJRvuIFFmoFjKEfYjUbHtaeI2RjnrZIYZSMrNqd1ZoT95Xiv ckjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=cuoU1kSVf8VEBS5kxyG+ti9eeLYydPT4J1CXt5LwLhU=; b=2vTyqrJlphwy/1W2ChFN9O10q0EWxpoqOVSmayYD+j6rHEiVkUBC4pbI5VZJZrQpFF YtsWqnkzrabOp/LDcuUgazuDMP7vSLe68+VxroQugmhlFAxldTG2ANctf572kqa8vXK4 AbbB2aKQA7qxsdFjR2F8kTlzrno/LaoW4nelgm6N33TxDhABG+0VcXh7yZZR/4+lm1it 7hPOhKfwbyZwd6W1Hv0GzF7t/A9GMIPX3HqStnIi4vthhaczuYN8GvJTIZ1hhNaUBN53 g2qt1S6MYi7jd56KhYkCJFs6LKpSAUdoFdUCXRyD+Ak5TNTrwEusKE4EfbN1kDm5r0nL oyqw== X-Gm-Message-State: AOAM532TUY9hqgG150K9zUSI9GYOqQR8FfNXdbaSqOz/dtJywEYS+8cf +GkJ9w5XC9xyzIBQ+nVI1ANP7Q== X-Google-Smtp-Source: ABdhPJxIe/y2ZbNmKFx3Owc3D12ozpXuX/TsxcZP+iWHDA2M91qfr82Tlpg84wHwV/O7VsilCNZp4w== X-Received: by 2002:a05:6870:14d5:b0:ec:ab0e:d106 with SMTP id l21-20020a05687014d500b000ecab0ed106mr469524oab.65.1651263471218; Fri, 29 Apr 2022 13:17:51 -0700 (PDT) Received: from localhost ([181.97.174.128]) by smtp.gmail.com with ESMTPSA id w12-20020a4ad02c000000b0035eb4e5a6aesm1130791oor.4.2022.04.29.13.17.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 29 Apr 2022 13:17:50 -0700 (PDT) From: Martin Fernandez To: linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org, platform-driver-x86@vger.kernel.org, linux-mm@kvack.org Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, ardb@kernel.org, dvhart@infradead.org, andy@infradead.org, gregkh@linuxfoundation.org, rafael@kernel.org, rppt@kernel.org, akpm@linux-foundation.org, daniel.gutson@eclypsium.com, hughsient@gmail.com, alex.bazhaniuk@eclypsium.com, alison.schofield@intel.com, keescook@chromium.org, Martin Fernandez Subject: [PATCH v8 2/8] mm/mmzone: Tag pg_data_t with crypto capabilities Date: Fri, 29 Apr 2022 17:17:11 -0300 Message-Id: <20220429201717.1946178-3-martin.fernandez@eclypsium.com> X-Mailer: git-send-email 2.30.2 In-Reply-To: <20220429201717.1946178-1-martin.fernandez@eclypsium.com> References: <20220429201717.1946178-1-martin.fernandez@eclypsium.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-efi@vger.kernel.org Add a new member in the pg_data_t struct to tell whether the node corresponding to that pg_data_t is able to do hardware memory encryption. This will be read from sysfs. Signed-off-by: Martin Fernandez --- include/linux/mmzone.h | 3 +++ mm/page_alloc.c | 1 + 2 files changed, 4 insertions(+) diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h index 46ffab808f03..89054af9e599 100644 --- a/include/linux/mmzone.h +++ b/include/linux/mmzone.h @@ -886,6 +886,9 @@ typedef struct pglist_data { struct task_struct *kcompactd; bool proactive_compact_trigger; #endif + + bool crypto_capable; + /* * This is a per-node reserve of pages that are not available * to userspace allocations. diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 0e42038382c1..a244151045b4 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -7699,6 +7699,7 @@ static void __init free_area_init_node(int nid) pgdat->node_id = nid; pgdat->node_start_pfn = start_pfn; pgdat->per_cpu_nodestats = NULL; + pgdat->crypto_capable = memblock_node_is_crypto_capable(nid); if (start_pfn != end_pfn) { pr_info("Initmem setup node %d [mem %#018Lx-%#018Lx]\n", nid, From patchwork Fri Apr 29 20:17:12 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Martin Fernandez X-Patchwork-Id: 568827 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 1245CC433FE for ; Fri, 29 Apr 2022 20:18:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1380490AbiD2UVU (ORCPT ); Fri, 29 Apr 2022 16:21:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51332 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1380496AbiD2UVU (ORCPT ); Fri, 29 Apr 2022 16:21:20 -0400 Received: from mail-oa1-x35.google.com (mail-oa1-x35.google.com [IPv6:2001:4860:4864:20::35]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 335EEA0BEA for ; Fri, 29 Apr 2022 13:18:00 -0700 (PDT) Received: by mail-oa1-x35.google.com with SMTP id 586e51a60fabf-d6e29fb3d7so9198136fac.7 for ; Fri, 29 Apr 2022 13:18:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eclypsium.com; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=bzJenq/qxXZmxxl1Ksk6HJARtm3Ihl+B/CevCTs1JBk=; b=OhU82U+6ILuhHnk9qZFELjk4MynpIJfr5fC/i1ZDSKydOzP1UPlko9p4vuh+p3AvnY dDMg917dkdnCGel1D0ix0GcLZSguMqbKosjPYJPbaC31yeqL9iyQuE/xj+rve5uKfzI+ UskmqyQt2XeV1aBJ973RpX1j9NiBXRRgag1fT6pNE71t1tEGhu25bMpqlsM9bh7rn7JU pEMT/Ia9fg255xXsDl30sEdLwH+sCSS1BsL9xQvM1d+GKSYKIbsdCf6K5XbF6S5cXZqz AZQWu2MesQczlNiuNErl7prDWp+cMY6wyxRIcWalI5vUrKARCo0tik1ffLJtUCWEKv0H 3Rqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=bzJenq/qxXZmxxl1Ksk6HJARtm3Ihl+B/CevCTs1JBk=; b=vN9RzFFWOSLYZD4uQkhlUOPNEdWLL31+1f5kDk6aObF1fJMUryi/UB0O4PuXIRG4nF EmIge2sVpFCxsJm6BC1pisKTbB1bvWnRiiBdtxVHAsvsQ6vjpeSJXCz4RHiWya0IZanx 4/w4uES5fd9D39hF7q+PmP073/G0p4u23hefdeEOwKWCXKxmc92DAsEPEFImRdrfw9SD c0IHGMZUrv8TmR7kS3vdLPztMD8jMEV6T+NIba+ifAsIjy+8u7CcYlLIT6QOOjbTx49M NbmgJZ7qNlO7dVsin1B1jOBAknKurXMDXlK+bXZVzJHHTyLRnotFbR4/x0/cC9hCzrYi 6TVQ== X-Gm-Message-State: AOAM533Xf82edLd+Y83CpNrzruCKpmmr5GxBhWG4t1tqnl7OMVSJBc2T 6FqmpCrztxu+KHpFyYCH2+yH2g== X-Google-Smtp-Source: ABdhPJyjjx8Jou1EYk06NDg5lvCjK/dBe+Yjuwv3tb5relSudRv03DIwoXeeO8KaVipm+iQer6YoHA== X-Received: by 2002:a05:6870:f5a3:b0:e1:944b:6450 with SMTP id eh35-20020a056870f5a300b000e1944b6450mr483469oab.254.1651263479419; Fri, 29 Apr 2022 13:17:59 -0700 (PDT) Received: from localhost ([181.97.174.128]) by smtp.gmail.com with ESMTPSA id p9-20020acabf09000000b00325cda1ff97sm70868oif.22.2022.04.29.13.17.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 29 Apr 2022 13:17:59 -0700 (PDT) From: Martin Fernandez To: linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org, platform-driver-x86@vger.kernel.org, linux-mm@kvack.org Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, ardb@kernel.org, dvhart@infradead.org, andy@infradead.org, gregkh@linuxfoundation.org, rafael@kernel.org, rppt@kernel.org, akpm@linux-foundation.org, daniel.gutson@eclypsium.com, hughsient@gmail.com, alex.bazhaniuk@eclypsium.com, alison.schofield@intel.com, keescook@chromium.org, Martin Fernandez Subject: [PATCH v8 3/8] x86/e820: Add infrastructure to refactor e820__range_{update,remove} Date: Fri, 29 Apr 2022 17:17:12 -0300 Message-Id: <20220429201717.1946178-4-martin.fernandez@eclypsium.com> X-Mailer: git-send-email 2.30.2 In-Reply-To: <20220429201717.1946178-1-martin.fernandez@eclypsium.com> References: <20220429201717.1946178-1-martin.fernandez@eclypsium.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-efi@vger.kernel.org __e820__range_update and e820__range_remove had a very similar flow in its implementation with a few lines different from each other, the lines that actually perform the modification over the e820_table. The similiraties were found in the checks for the different cases on how each entry intersects with the given range (if it does at all). These checks were very presice and error prone so it was not a good idea to have them in both places. Since I need to add a third one, similar to this two, in this and the following patches I'll propose a refactor of these functions. In this patch I introduce: - A new type e820_entry_updater that will carry three callbacks, those callbacks will decide WHEN to perform actions over the e820_table and WHAY actions are going to be performed. Note that there is a void pointer "data". This pointer will carry useful information for the callbacks, like the type that we want to update in e820__range_update or if we want to check the type in e820__range_remove. Check it out in the next patches where I do the rework of __e820__range_update and e820__range_remove. - A new function __e820__handle_range_update that has the flow of the original two functions to refactor. Together with e820_entry_updater will perform the desired update on the input table. On version 6 of this patch some people pointed out that this solution was over-complicated. Mike Rapoport suggested a another solution [1]. I took a look at that, and although it is indeed simpler it's more confusing at the same time. I think is manageable to have a single function to update or remove sections of the table (what Mike did), but when I added the functionality to also update the crypto_capable it became really hard to manage. I think that the approach presented in this patch it's complex but is easier to read, to extend and to test. [1] https://git.kernel.org/rppt/h/x86/e820-update-range Signed-off-by: Martin Fernandez -------------------------------------------------- Changes from v7 to v8: (Some) Callbacks of e820_entry_updater can now be NULL to avoid defining empty functions Remove kerneldocs in favor of plain comments just to explain what the functions do. --- arch/x86/kernel/e820.c | 127 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 127 insertions(+) diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c index f267205f2d5a..e0fa3ab755a5 100644 --- a/arch/x86/kernel/e820.c +++ b/arch/x86/kernel/e820.c @@ -459,6 +459,133 @@ static int __init append_e820_table(struct boot_e820_entry *entries, u32 nr_entr return __append_e820_table(entries, nr_entries); } +/** + * struct e820_entry_updater - Helper type for + * __e820__handle_range_update(). + * @should_update: Return true if @entry needs to be updated, false + * otherwise. + * @update: Apply desired actions to an @entry that is inside the + * range and satisfies @should_update. Can be set to NULL to avoid empty functions. + * @new: Create new entry in the table with information gathered from + * @original and @data. Can be set to NULL to avoid empty functions. + * + * Each function corresponds to an action that + * __e820__handle_range_update() does. Callbacks need to cast @data back + * to the corresponding type. + */ +struct e820_entry_updater { + bool (*should_update)(const struct e820_entry *entry, const void *data); + void (*update)(struct e820_entry *entry, const void *data); + void (*new)(struct e820_table *table, u64 new_start, u64 new_size, + const struct e820_entry *original, const void *data); +}; + +/* + * Helper for __e820__handle_range_update to handle the case where + * neither the entry completely covers the range nor the range + * completely covers the entry. + */ +static u64 __init +__e820__handle_intersected_range_update(struct e820_table *table, + u64 start, + u64 size, + struct e820_entry *entry, + const struct e820_entry_updater *updater, + const void *data) +{ + u64 end; + u64 entry_end = entry->addr + entry->size; + u64 inner_start; + u64 inner_end; + u64 updated_size = 0; + + if (size > (ULLONG_MAX - start)) + size = ULLONG_MAX - start; + + end = start + size; + inner_start = max(start, entry->addr); + inner_end = min(end, entry_end); + + /* Range and entry do intersect and... */ + if (inner_start < inner_end) { + /* Entry is on the left */ + if (entry->addr < inner_start) { + /* Resize current entry */ + entry->size = inner_start - entry->addr; + /* Entry is on the right */ + } else { + /* Resize and move current section */ + entry->addr = inner_end; + entry->size = entry_end - inner_end; + } + if (updater->new != NULL) + /* Create new entry with intersected region */ + updater->new(table, inner_start, inner_end - inner_start, entry, data); + + updated_size += inner_end - inner_start; + } /* Else: [start, end) doesn't cover entry */ + + return updated_size; +} + +/* + * Update the table @table in [@start, @start + @size) doing the + * actions given in @updater. + */ +static u64 __init +__e820__handle_range_update(struct e820_table *table, + u64 start, + u64 size, + const struct e820_entry_updater *updater, + const void *data) +{ + u64 updated_size = 0; + u64 end; + unsigned int i; + + if (size > (ULLONG_MAX - start)) + size = ULLONG_MAX - start; + + end = start + size; + + for (i = 0; i < table->nr_entries; i++) { + struct e820_entry *entry = &table->entries[i]; + u64 entry_end = entry->addr + entry->size; + + if (updater->should_update(entry, data)) { + /* Range completely covers entry */ + if (entry->addr >= start && entry_end <= end) { + updated_size += entry->size; + if (updater->update != NULL) + updater->update(entry, data); + /* Entry completely covers range */ + } else if (start > entry->addr && end < entry_end) { + /* Resize current entry */ + entry->size = start - entry->addr; + + if (updater->new != NULL) + /* Create new entry with intersection region */ + updater->new(table, start, size, entry, data); + + /* + * Create a new entry for the leftover + * of the current entry + */ + __e820__range_add(table, end, entry_end - end, + entry->type); + + updated_size += size; + } else { + updated_size += + __e820__handle_intersected_range_update(table, start, size, + entry, updater, data); + } + } + } + + return updated_size; +} + static u64 __init __e820__range_update(struct e820_table *table, u64 start, u64 size, enum e820_type old_type, enum e820_type new_type) { From patchwork Fri Apr 29 20:17:13 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Martin Fernandez X-Patchwork-Id: 567602 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 755D1C433F5 for ; Fri, 29 Apr 2022 20:18:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1380630AbiD2UVc (ORCPT ); Fri, 29 Apr 2022 16:21:32 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52126 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1344512AbiD2UV3 (ORCPT ); Fri, 29 Apr 2022 16:21:29 -0400 Received: from mail-oa1-x36.google.com (mail-oa1-x36.google.com [IPv6:2001:4860:4864:20::36]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BFF40C8A9F for ; Fri, 29 Apr 2022 13:18:07 -0700 (PDT) Received: by mail-oa1-x36.google.com with SMTP id 586e51a60fabf-deb9295679so9217403fac.6 for ; Fri, 29 Apr 2022 13:18:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eclypsium.com; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=PLuObBmPkIWHGGIa0YgrZ0Lq4zFfhIdvg//A8xn7ggo=; b=bDqZaABFMgbCLkZSOOaIqWXwNxKq7mseURB3Uho4ueCz1dK5Sg5oiQmKB6FATHblrP jxnZ4zLyyzM4un446F22ja4cDAw0P+SRSXKTENRKrNSkVExlDHbFvvsDAMKzQahVqNEe X+hCpEFt+iz78gB+HqjFukCBu2GzDKsy4ueixp7I0CdFYyCkriviEhAVL8OZIBD7ik2q 0GKnnbWIfLfaHOTPuDSlf0Cixh6bNynHXSQwTNdfmXYveHNXxLJZb6uvzHRaKx5skZRH 1KxzopzMkI8RB0enn0HThdgeAIc2RAcq2FZit5fIVYtbtANMzb4NCuRHfNtkZrYF3bON EUCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=PLuObBmPkIWHGGIa0YgrZ0Lq4zFfhIdvg//A8xn7ggo=; b=rqQ1pYX1c02Yea8W4klFhXPqbpMtjN7WXsYSNLAmE5B1EresnksjFcFZ9pMclMJXAn Sk4jXv9l+EOeJxyysXIJ5W5dFTF+z+8C4g5K+RO6o62fmTdYYFP/mYsqZuPjwdojS1S4 ODiLiZVpgdWcRqG1PRoyXZ0+kmY16smptlqzzyTMczOXMkQ8n/yps9uj9po3wtt0ubwt KYkyWGVVTUStoAFhVyE43m8lGe+kTzR7onBMQfdUTO/SXckFDnYDWmD/W0D20cV1PnEM ONZ9gdVMf7DRodSXBz3fYMHFfSPi/m5lTP4pNZpHzDzXvFeyJ7ls2f7pGWg6gWap/bOg 0qOw== X-Gm-Message-State: AOAM530a+Buj+0Xawx4LdDNOsvBTob9hDGguEFnKxfz1RtNcevr62lcP Wpfa7FQoZdFG6NqA6+bv3hmyUw== X-Google-Smtp-Source: ABdhPJzrZ8Kfl4T49yQr7FGvWCo8iE92bI2DDqgrilNpiLxjJDpWs/nerrD+omBLCh+QcoMFJfgdCQ== X-Received: by 2002:a05:6870:708a:b0:e9:9349:9410 with SMTP id v10-20020a056870708a00b000e993499410mr2067692oae.265.1651263487078; Fri, 29 Apr 2022 13:18:07 -0700 (PDT) Received: from localhost ([181.97.174.128]) by smtp.gmail.com with ESMTPSA id q2-20020a056808200200b00325cda1ff9dsm71731oiw.28.2022.04.29.13.18.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 29 Apr 2022 13:18:06 -0700 (PDT) From: Martin Fernandez To: linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org, platform-driver-x86@vger.kernel.org, linux-mm@kvack.org Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, ardb@kernel.org, dvhart@infradead.org, andy@infradead.org, gregkh@linuxfoundation.org, rafael@kernel.org, rppt@kernel.org, akpm@linux-foundation.org, daniel.gutson@eclypsium.com, hughsient@gmail.com, alex.bazhaniuk@eclypsium.com, alison.schofield@intel.com, keescook@chromium.org, Martin Fernandez Subject: [PATCH v8 4/8] x86/e820: Refactor __e820__range_update Date: Fri, 29 Apr 2022 17:17:13 -0300 Message-Id: <20220429201717.1946178-5-martin.fernandez@eclypsium.com> X-Mailer: git-send-email 2.30.2 In-Reply-To: <20220429201717.1946178-1-martin.fernandez@eclypsium.com> References: <20220429201717.1946178-1-martin.fernandez@eclypsium.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-efi@vger.kernel.org Refactor __e820__range_update with the introduction of e820_type_updater_data, indented to be used as the void pointer in the e820_entry_updater callbacks, and the implementation of the callbacks to perform the update of the type in a range of a e820_table. Signed-off-by: Martin Fernandez --- arch/x86/kernel/e820.c | 119 +++++++++++++++++++++-------------------- 1 file changed, 62 insertions(+), 57 deletions(-) diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c index e0fa3ab755a5..36a22c0a2199 100644 --- a/arch/x86/kernel/e820.c +++ b/arch/x86/kernel/e820.c @@ -586,80 +586,85 @@ __e820__handle_range_update(struct e820_table *table, return updated_size; } -static u64 __init -__e820__range_update(struct e820_table *table, u64 start, u64 size, enum e820_type old_type, enum e820_type new_type) -{ - u64 end; - unsigned int i; - u64 real_updated_size = 0; - - BUG_ON(old_type == new_type); - - if (size > (ULLONG_MAX - start)) - size = ULLONG_MAX - start; +/* + * Type helper for the e820_entry_updater callbacks. + */ +struct e820_type_updater_data { + enum e820_type old_type; + enum e820_type new_type; +}; - end = start + size; - printk(KERN_DEBUG "e820: update [mem %#010Lx-%#010Lx] ", start, end - 1); - e820_print_type(old_type); - pr_cont(" ==> "); - e820_print_type(new_type); - pr_cont("\n"); +static bool __init type_updater__should_update(const struct e820_entry *entry, + const void *data) +{ + const struct e820_type_updater_data *type_updater_data = data; - for (i = 0; i < table->nr_entries; i++) { - struct e820_entry *entry = &table->entries[i]; - u64 final_start, final_end; - u64 entry_end; + return entry->type == type_updater_data->old_type; +} - if (entry->type != old_type) - continue; +static void __init type_updater__update(struct e820_entry *entry, + const void *data) +{ + const struct e820_type_updater_data *type_updater_data = data; - entry_end = entry->addr + entry->size; + entry->type = type_updater_data->new_type; +} - /* Completely covered by new range? */ - if (entry->addr >= start && entry_end <= end) { - entry->type = new_type; - real_updated_size += entry->size; - continue; - } +static void __init type_updater__new(struct e820_table *table, u64 new_start, + u64 new_size, + const struct e820_entry *original, + const void *data) +{ + const struct e820_type_updater_data *type_updater_data = data; - /* New range is completely covered? */ - if (entry->addr < start && entry_end > end) { - __e820__range_add(table, start, size, new_type); - __e820__range_add(table, end, entry_end - end, entry->type); - entry->size = start - entry->addr; - real_updated_size += size; - continue; - } + __e820__range_add(table, new_start, new_size, + type_updater_data->new_type); +} - /* Partially covered: */ - final_start = max(start, entry->addr); - final_end = min(end, entry_end); - if (final_start >= final_end) - continue; +static u64 __init __e820__range_update(struct e820_table *table, u64 start, + u64 size, enum e820_type old_type, + enum e820_type new_type) +{ + struct e820_entry_updater updater = { + .should_update = type_updater__should_update, + .update = type_updater__update, + .new = type_updater__new + }; - __e820__range_add(table, final_start, final_end - final_start, new_type); + struct e820_type_updater_data data = { + .old_type = old_type, + .new_type = new_type + }; - real_updated_size += final_end - final_start; + BUG_ON(old_type == new_type); - /* - * Left range could be head or tail, so need to update - * its size first: - */ - entry->size -= final_end - final_start; - if (entry->addr < final_start) - continue; + printk(KERN_DEBUG "e820: update [mem %#018Lx-%#018Lx] ", start, + start + size - 1); + e820_print_type(old_type); + pr_cont(" ==> "); + e820_print_type(new_type); + pr_cont("\n"); - entry->addr = final_end; - } - return real_updated_size; + return __e820__handle_range_update(table, start, size, &updater, &data); } -u64 __init e820__range_update(u64 start, u64 size, enum e820_type old_type, enum e820_type new_type) +/* + * Update type of addresses in [@start, @start + @size) from @old_type + * to @new_type in e820_table. + */ +u64 __init e820__range_update(u64 start, u64 size, enum e820_type old_type, + enum e820_type new_type) { return __e820__range_update(e820_table, start, size, old_type, new_type); } -static u64 __init e820__range_update_kexec(u64 start, u64 size, enum e820_type old_type, enum e820_type new_type) +/* + * Update type of addresses in [@start, @start + @size) from @old_type + * to @new_type in e820_table_kexec. + */ +static u64 __init e820__range_update_kexec(u64 start, u64 size, + enum e820_type old_type, + enum e820_type new_type) { return __e820__range_update(e820_table_kexec, start, size, old_type, new_type); } From patchwork Fri Apr 29 20:17:14 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Martin Fernandez X-Patchwork-Id: 568826 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 A9C4BC433F5 for ; Fri, 29 Apr 2022 20:18:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1380651AbiD2UVf (ORCPT ); Fri, 29 Apr 2022 16:21:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52210 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1380631AbiD2UVe (ORCPT ); Fri, 29 Apr 2022 16:21:34 -0400 Received: from mail-oa1-x32.google.com (mail-oa1-x32.google.com [IPv6:2001:4860:4864:20::32]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 57C06C84A6 for ; Fri, 29 Apr 2022 13:18:15 -0700 (PDT) Received: by mail-oa1-x32.google.com with SMTP id 586e51a60fabf-e9027efe6aso9186603fac.10 for ; Fri, 29 Apr 2022 13:18:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eclypsium.com; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=rnE47zkhbqWUJCOF0oFEixfkiu1ztx/JWB/tGri5YXI=; b=a9eja63UZsOz8EDkYCqgng2hYRK9WULHVEyppQTAGE6xiRQ32CQn6CFl2j4IpY4D/A T/SILFH1b9jXsHfFF5EPdcHdjPOQ9tzsyECf/C+2FrfimR8jZwXFDAoZPcRS1M6y+YZU wqaNac66Z0pUqdAQgcZpXr/lksm1XFEayCYcjPohjvqxfH61LHyxYLHEC3VoBP/SSzw6 +d1offiCPqehXEje4lXOw68Qk4XWAXNcjzTeC5lZsbpYcAnKW0lB9/YmgZkZTuGojgMQ nFGLT6sdanVPtlGuzu30Ol+fmyRWCBmYGhBBv1OwuLHUY5MzLq8ev+Bm6J9a8H06rP/0 QQbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=rnE47zkhbqWUJCOF0oFEixfkiu1ztx/JWB/tGri5YXI=; b=Pn3vvxOTdHwSv6shcQgiY20t7rV2YiR2EYOlEabqWpqrCCc1kG2pdS2qxPqRcJuIRn 1WfqDbkT2YdZh7icwOMSk3v0s08f6rnoGvsSr/19Jgnu15os2lutNYId37IMiX02zswV SZQhTz/0LvrBzKsI6fflxABKoWxkYvHqyHCo8gIph+33aa3lLDV1+fSgRf9gJhAbnSkm wVlJv3qXyctXHMu4LI/VaN1I/Z43iyYwBmNZu8IwS1AwMLN3cF2zhTmCgqzWmFVY6BMw jjBNv+JVIi25D6JdHTscMhcH/PtrSXtBuZq+q3ZL6SNOAoEO6T5u9m/rgEtChC32Ybdj y2KA== X-Gm-Message-State: AOAM533Jtja3RAYnjuKAqpnyAS8nd+wcgTKc3sxGMcx1C7AgJR55LBey M3LrIfh2hvSXPzt7zN1RP7GDzQ== X-Google-Smtp-Source: ABdhPJxofcGdrQu7m+cL6vOtGym7ome4qtIu2YMefSz1hnwtbmQ4+6AReZ8mcS6ebQmZ4VwoWkIanA== X-Received: by 2002:a05:6871:28a:b0:e9:16de:c70d with SMTP id i10-20020a056871028a00b000e916dec70dmr477455oae.113.1651263494682; Fri, 29 Apr 2022 13:18:14 -0700 (PDT) Received: from localhost ([181.97.174.128]) by smtp.gmail.com with ESMTPSA id p4-20020a0568301d4400b0060603221248sm85961oth.24.2022.04.29.13.18.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 29 Apr 2022 13:18:14 -0700 (PDT) From: Martin Fernandez To: linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org, platform-driver-x86@vger.kernel.org, linux-mm@kvack.org Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, ardb@kernel.org, dvhart@infradead.org, andy@infradead.org, gregkh@linuxfoundation.org, rafael@kernel.org, rppt@kernel.org, akpm@linux-foundation.org, daniel.gutson@eclypsium.com, hughsient@gmail.com, alex.bazhaniuk@eclypsium.com, alison.schofield@intel.com, keescook@chromium.org, Martin Fernandez Subject: [PATCH v8 5/8] x86/e820: Refactor e820__range_remove Date: Fri, 29 Apr 2022 17:17:14 -0300 Message-Id: <20220429201717.1946178-6-martin.fernandez@eclypsium.com> X-Mailer: git-send-email 2.30.2 In-Reply-To: <20220429201717.1946178-1-martin.fernandez@eclypsium.com> References: <20220429201717.1946178-1-martin.fernandez@eclypsium.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-efi@vger.kernel.org Refactor e820__range_remove with the introduction of e820_remover_data, indented to be used as the void pointer in the e820_entry_updater callbacks, and the implementation of the callbacks remove a range in the e820_table. Signed-off-by: Martin Fernandez --- arch/x86/kernel/e820.c | 94 ++++++++++++++++++------------------------ 1 file changed, 41 insertions(+), 53 deletions(-) diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c index 36a22c0a2199..0e5aa13ebdb8 100644 --- a/arch/x86/kernel/e820.c +++ b/arch/x86/kernel/e820.c @@ -669,66 +669,54 @@ static u64 __init e820__range_update_kexec(u64 start, u64 size, return __e820__range_update(e820_table_kexec, start, size, old_type, new_type); } -/* Remove a range of memory from the E820 table: */ -u64 __init e820__range_remove(u64 start, u64 size, enum e820_type old_type, bool check_type) -{ - int i; - u64 end; - u64 real_removed_size = 0; - - if (size > (ULLONG_MAX - start)) - size = ULLONG_MAX - start; - - end = start + size; - printk(KERN_DEBUG "e820: remove [mem %#010Lx-%#010Lx] ", start, end - 1); - if (check_type) - e820_print_type(old_type); - pr_cont("\n"); - - for (i = 0; i < e820_table->nr_entries; i++) { - struct e820_entry *entry = &e820_table->entries[i]; - u64 final_start, final_end; - u64 entry_end; - - if (check_type && entry->type != old_type) - continue; +/* + * Type helper for the e820_entry_updater callbacks. + */ +struct e820_remover_data { + enum e820_type old_type; + bool check_type; +}; - entry_end = entry->addr + entry->size; +static bool __init remover__should_update(const struct e820_entry *entry, + const void *data) +{ + const struct e820_remover_data *remover_data = data; - /* Completely covered? */ - if (entry->addr >= start && entry_end <= end) { - real_removed_size += entry->size; - memset(entry, 0, sizeof(*entry)); - continue; - } + return !remover_data->check_type || + entry->type == remover_data->old_type; +} - /* Is the new range completely covered? */ - if (entry->addr < start && entry_end > end) { - e820__range_add(end, entry_end - end, entry->type); - entry->size = start - entry->addr; - real_removed_size += size; - continue; - } +static void __init remover__update(struct e820_entry *entry, const void *data) +{ + memset(entry, 0, sizeof(*entry)); +} - /* Partially covered: */ - final_start = max(start, entry->addr); - final_end = min(end, entry_end); - if (final_start >= final_end) - continue; +/* + * Remove [@start, @start + @size) from e820_table. If @check_type is + * true remove only entries with type @old_type. + */ +u64 __init e820__range_remove(u64 start, u64 size, enum e820_type old_type, + bool check_type) +{ + struct e820_entry_updater updater = { + .should_update = remover__should_update, + .update = remover__update, + .new = NULL + }; - real_removed_size += final_end - final_start; + struct e820_remover_data data = { + .check_type = check_type, + .old_type = old_type + }; - /* - * Left range could be head or tail, so need to update - * the size first: - */ - entry->size -= final_end - final_start; - if (entry->addr < final_start) - continue; + printk(KERN_DEBUG "e820: remove [mem %#018Lx-%#018Lx] ", start, + start + size - 1); + if (check_type) + e820_print_type(old_type); + pr_cont("\n"); - entry->addr = final_end; - } - return real_removed_size; + return __e820__handle_range_update(e820_table, start, size, &updater, + &data); } void __init e820__update_table_print(void) From patchwork Fri Apr 29 20:17:15 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Martin Fernandez X-Patchwork-Id: 567601 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 232D0C433F5 for ; Fri, 29 Apr 2022 20:18:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1380661AbiD2UVs (ORCPT ); Fri, 29 Apr 2022 16:21:48 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52314 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1380660AbiD2UVm (ORCPT ); Fri, 29 Apr 2022 16:21:42 -0400 Received: from mail-oa1-x2f.google.com (mail-oa1-x2f.google.com [IPv6:2001:4860:4864:20::2f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B6215D5E86 for ; Fri, 29 Apr 2022 13:18:22 -0700 (PDT) Received: by mail-oa1-x2f.google.com with SMTP id 586e51a60fabf-e922e68b0fso9245119fac.1 for ; Fri, 29 Apr 2022 13:18:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eclypsium.com; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=YiEyrkk7zAfWqeyIGUzFkmdI1NMExWAuPYFixtI2XBY=; b=C8/S+PsjTKCTWs7QPbmskNwv0xJZf36RcyWfiPYmgT8PUdBZ0LEt7cVJsQ3qusPUoF Ro4owjn5KseQ6TVU9ePDoGObhGhAcy57k9X8gFCm62pOrVhaxG2OzRgRQTyCk6gZlSJ/ Ysk5lQ2z9WTQ29acnkhjhROEJG8RNCjJfXrBWIV3snlVPHOckkq65ntZadqn59UmgVaN TaH55DhJ/W20T529+4pOBkro+wVtKCEjP9K3Ry7qObQT/YeMJ0iZfaGNqVKSwqKEQ2JZ b111PVjSTWJ4BQ4Tx01B/lbF0nVywroAZowdHYnxd/WL8u4dICC9gOnOd9epHshrm8Ay MUQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=YiEyrkk7zAfWqeyIGUzFkmdI1NMExWAuPYFixtI2XBY=; b=yKM2DisyuJnzxPe3HUYjQOFtpfmspUVxrAYaA3+RrHZ/pAtD8fnhBndDRlBnnr79aK CQdT424akH1R7xzPoa27weWXJNuTXD4r2xQlko6LTvNPEUXAZnWhFE2i6UUno72qM4/H e8E114Z9dQKAH1h4Mcfrm6N/ApIvC9gg6lS0QShI4WS2iJwHiqoajrF4yYA/Tc+u4Nhe xwGmGKTqze8rM5bWO2mmwMZrpukaAtzchGOpozpCZDu57zkM7Xv3cLfQ4fEg/KfHV2zB 6AO9JJaQ4W7EUVoTU8CV7rvVcWq5qp1erdlg4QdsH3Zul1x9fRqz8XnefBGYZipM/inZ 3lQg== X-Gm-Message-State: AOAM530oI9Ih4kZpWT6ayHPY9PH3tMYFx7oHX6fS8kcNPYRLhbgSiqje 77AxsMyxQ8yQnfAcqRHTUoHnzQ== X-Google-Smtp-Source: ABdhPJySjyVhXI/q/lRO3rvx7oHsGnM1batE9Jn9hgdgQQAem2lB2nDHyoKkEPlP1FFibHKjQkq49A== X-Received: by 2002:a05:6870:c108:b0:e9:49d9:1666 with SMTP id f8-20020a056870c10800b000e949d91666mr464920oad.243.1651263502055; Fri, 29 Apr 2022 13:18:22 -0700 (PDT) Received: from localhost ([181.97.174.128]) by smtp.gmail.com with ESMTPSA id m4-20020a056870030400b000e686d13890sm3310318oaf.42.2022.04.29.13.18.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 29 Apr 2022 13:18:21 -0700 (PDT) From: Martin Fernandez To: linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org, platform-driver-x86@vger.kernel.org, linux-mm@kvack.org Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, ardb@kernel.org, dvhart@infradead.org, andy@infradead.org, gregkh@linuxfoundation.org, rafael@kernel.org, rppt@kernel.org, akpm@linux-foundation.org, daniel.gutson@eclypsium.com, hughsient@gmail.com, alex.bazhaniuk@eclypsium.com, alison.schofield@intel.com, keescook@chromium.org, Martin Fernandez Subject: [PATCH v8 6/8] x86/e820: Tag e820_entry with crypto capabilities Date: Fri, 29 Apr 2022 17:17:15 -0300 Message-Id: <20220429201717.1946178-7-martin.fernandez@eclypsium.com> X-Mailer: git-send-email 2.30.2 In-Reply-To: <20220429201717.1946178-1-martin.fernandez@eclypsium.com> References: <20220429201717.1946178-1-martin.fernandez@eclypsium.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-efi@vger.kernel.org Add a new enum for crypto capabilities. I choosed an enum instead of a boolean for more visibility in the code and because maybe in the future we would like to track from where the cryptographic capabilities comes (in this case, the EFI memmap). Add a new member in e820_entry to hold this new enum. Add a new function e820__range_set_crypto_capable to mark all the entries in a range of addresses as encryptable. This will be called when initializing EFI. Change e820__update_table to handle merging and overlap problems taking into account crypto_capable. Signed-off-by: Martin Fernandez --- arch/x86/include/asm/e820/api.h | 1 + arch/x86/include/asm/e820/types.h | 12 +++-- arch/x86/kernel/e820.c | 88 +++++++++++++++++++++++++++++-- 3 files changed, 93 insertions(+), 8 deletions(-) diff --git a/arch/x86/include/asm/e820/api.h b/arch/x86/include/asm/e820/api.h index e8f58ddd06d9..4b3b01fafdd1 100644 --- a/arch/x86/include/asm/e820/api.h +++ b/arch/x86/include/asm/e820/api.h @@ -17,6 +17,7 @@ extern bool e820__mapped_all(u64 start, u64 end, enum e820_type type); extern void e820__range_add (u64 start, u64 size, enum e820_type type); extern u64 e820__range_update(u64 start, u64 size, enum e820_type old_type, enum e820_type new_type); extern u64 e820__range_remove(u64 start, u64 size, enum e820_type old_type, bool check_type); +extern u64 e820__range_set_crypto_capable(u64 start, u64 size); extern void e820__print_table(char *who); extern int e820__update_table(struct e820_table *table); diff --git a/arch/x86/include/asm/e820/types.h b/arch/x86/include/asm/e820/types.h index 314f75d886d0..aef03c665f5e 100644 --- a/arch/x86/include/asm/e820/types.h +++ b/arch/x86/include/asm/e820/types.h @@ -46,6 +46,11 @@ enum e820_type { E820_TYPE_RESERVED_KERN = 128, }; +enum e820_crypto_capabilities { + E820_NOT_CRYPTO_CAPABLE = 0, + E820_CRYPTO_CAPABLE = 1, +}; + /* * A single E820 map entry, describing a memory range of [addr...addr+size-1], * of 'type' memory type: @@ -53,9 +58,10 @@ enum e820_type { * (We pack it because there can be thousands of them on large systems.) */ struct e820_entry { - u64 addr; - u64 size; - enum e820_type type; + u64 addr; + u64 size; + enum e820_type type; + enum e820_crypto_capabilities crypto_capable; } __attribute__((packed)); /* diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c index 0e5aa13ebdb8..dade59758b9f 100644 --- a/arch/x86/kernel/e820.c +++ b/arch/x86/kernel/e820.c @@ -163,7 +163,9 @@ int e820__get_entry_type(u64 start, u64 end) /* * Add a memory region to the kernel E820 map. */ -static void __init __e820__range_add(struct e820_table *table, u64 start, u64 size, enum e820_type type) +static void __init __e820__range_add(struct e820_table *table, u64 start, + u64 size, enum e820_type type, + enum e820_crypto_capabilities crypto_capable) { int x = table->nr_entries; @@ -176,12 +178,13 @@ static void __init __e820__range_add(struct e820_table *table, u64 start, u64 si table->entries[x].addr = start; table->entries[x].size = size; table->entries[x].type = type; + table->entries[x].crypto_capable = crypto_capable; table->nr_entries++; } void __init e820__range_add(u64 start, u64 size, enum e820_type type) { - __e820__range_add(e820_table, start, size, type); + __e820__range_add(e820_table, start, size, type, E820_NOT_CRYPTO_CAPABLE); } static void __init e820_print_type(enum e820_type type) @@ -211,6 +214,8 @@ void __init e820__print_table(char *who) e820_table->entries[i].addr + e820_table->entries[i].size - 1); e820_print_type(e820_table->entries[i].type); + if (e820_table->entries[i].crypto_capable == E820_CRYPTO_CAPABLE) + pr_cont("; crypto-capable"); pr_cont("\n"); } } @@ -327,6 +332,7 @@ int __init e820__update_table(struct e820_table *table) unsigned long long last_addr; u32 new_nr_entries, overlap_entries; u32 i, chg_idx, chg_nr; + enum e820_crypto_capabilities current_crypto, last_crypto; /* If there's only one memory region, don't bother: */ if (table->nr_entries < 2) @@ -367,6 +373,7 @@ int __init e820__update_table(struct e820_table *table) new_nr_entries = 0; /* Index for creating new map entries */ last_type = 0; /* Start with undefined memory type */ last_addr = 0; /* Start with 0 as last starting address */ + last_crypto = E820_NOT_CRYPTO_CAPABLE; /* Loop through change-points, determining effect on the new map: */ for (chg_idx = 0; chg_idx < chg_nr; chg_idx++) { @@ -388,13 +395,19 @@ int __init e820__update_table(struct e820_table *table) * 1=usable, 2,3,4,4+=unusable) */ current_type = 0; + current_crypto = E820_CRYPTO_CAPABLE; for (i = 0; i < overlap_entries; i++) { + if (overlap_list[i]->crypto_capable < current_crypto) + current_crypto = overlap_list[i]->crypto_capable; + if (overlap_list[i]->type > current_type) current_type = overlap_list[i]->type; } /* Continue building up new map based on this information: */ - if (current_type != last_type || e820_nomerge(current_type)) { + if (current_type != last_type || + current_crypto != last_crypto || + e820_nomerge(current_type)) { if (last_type != 0) { new_entries[new_nr_entries].size = change_point[chg_idx]->addr - last_addr; /* Move forward only if the new size was non-zero: */ @@ -406,9 +419,12 @@ int __init e820__update_table(struct e820_table *table) if (current_type != 0) { new_entries[new_nr_entries].addr = change_point[chg_idx]->addr; new_entries[new_nr_entries].type = current_type; + new_entries[new_nr_entries].crypto_capable = current_crypto; + last_addr = change_point[chg_idx]->addr; } last_type = current_type; + last_crypto = current_crypto; } } @@ -572,7 +588,8 @@ __e820__handle_range_update(struct e820_table *table, * of the current entry */ __e820__range_add(table, end, entry_end - end, - entry->type); + entry->type, + entry->crypto_capable); updated_size += size; } else { @@ -618,7 +635,8 @@ static void __init type_updater__new(struct e820_table *table, u64 new_start, const struct e820_type_updater_data *type_updater_data = data; __e820__range_add(table, new_start, new_size, - type_updater_data->new_type); + type_updater_data->new_type, + original->crypto_capable); } static u64 __init __e820__range_update(struct e820_table *table, u64 start, @@ -719,6 +737,64 @@ u64 __init e820__range_remove(u64 start, u64 size, enum e820_type old_type, &data); } +static bool __init crypto_updater__should_update(const struct e820_entry *entry, + const void *data) +{ + const enum e820_crypto_capabilities *crypto_capable = data; + + return *crypto_capable != entry->crypto_capable; +} + +static void __init crypto_updater__update(struct e820_entry *entry, + const void *data) +{ + const enum e820_crypto_capabilities *crypto_capable = data; + + entry->crypto_capable = *crypto_capable; +} + +static void __init crypto_updater__new(struct e820_table *table, u64 new_start, + u64 new_size, + const struct e820_entry *original, + const void *data) +{ + const enum e820_crypto_capabilities *crypto_capable = data; + + __e820__range_add(table, new_start, new_size, original->type, *crypto_capable); +} + +static u64 __init +__e820__range_update_crypto(struct e820_table *table, u64 start, u64 size, + enum e820_crypto_capabilities crypto_capable) +{ + struct e820_entry_updater updater = { + .should_update = crypto_updater__should_update, + .update = crypto_updater__update, + .new = crypto_updater__new + }; + + printk(KERN_DEBUG "e820: crypto update [mem %#018Lx-%#018Lx]", start, + start + size - 1); + pr_cont(" ==> "); + if (crypto_capable == E820_CRYPTO_CAPABLE) + pr_cont("crypto capable"); + else + pr_cont("not crypto capable"); + pr_cont("\n"); + + return __e820__handle_range_update(table, start, size, &updater, + &crypto_capable); +} + +/* + * Set %E820_CRYPTO_CAPABLE to [@start, @start + @size) in e820_table. + */ +u64 __init e820__range_set_crypto_capable(u64 start, u64 size) +{ + return __e820__range_update_crypto(e820_table, start, size, + E820_CRYPTO_CAPABLE); +} + void __init e820__update_table_print(void) { if (e820__update_table(e820_table)) @@ -1461,6 +1537,8 @@ void __init e820__memblock_setup(void) continue; memblock_add(entry->addr, entry->size); + if (entry->crypto_capable == E820_CRYPTO_CAPABLE) + memblock_mark_crypto_capable(entry->addr, entry->size); } /* Throw away partial pages: */ From patchwork Fri Apr 29 20:17:16 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Martin Fernandez X-Patchwork-Id: 568825 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 AC195C4332F for ; Fri, 29 Apr 2022 20:18:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1380671AbiD2UVu (ORCPT ); Fri, 29 Apr 2022 16:21:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52420 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345389AbiD2UVt (ORCPT ); Fri, 29 Apr 2022 16:21:49 -0400 Received: from mail-oa1-x2e.google.com (mail-oa1-x2e.google.com [IPv6:2001:4860:4864:20::2e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1F819CFE7C for ; Fri, 29 Apr 2022 13:18:30 -0700 (PDT) Received: by mail-oa1-x2e.google.com with SMTP id 586e51a60fabf-deb9295679so9218182fac.6 for ; Fri, 29 Apr 2022 13:18:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eclypsium.com; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=2VGMhr11GA+eGLRm5CsL28eo528BHkwYTiIF+ncvNsE=; b=BvRseK4OxKadqHo12yNsfQ37dcGHfwzf2NABqSmUh4dW14GFsCZ9lNoqxOaprhkpIt RD4NewzP3DKtjv3EXexgwnPx9/D0SPPyIwy17W+pLoOmfBWGYsEfnwEcCoqicMULz7s7 xgniOuDmDzPksbBOjq8y3XGwMK8aG73pFr7TQbKHrtYnU5S3KN9v9vUdtdfvpBBLl6pG /+bPXmuJin8w9zaqauKrTz+CbnNMDCN4Mue5L9B5DMPEnXDbpbTYpDkcgT11Ay11MmVy mMF1NeIq5CeN9ZfsuwJpnFNuT3ReobQHJCtBWNx1hbcv8Gc1Y6Hc7fGasrUup9XPtJfy F/uQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=2VGMhr11GA+eGLRm5CsL28eo528BHkwYTiIF+ncvNsE=; b=4ood9fPpTRn2Y8res9d4v3h9rR5lTu4QTdrDOxPi24Z9BLJDwfKaIyM6G00JtcK0RK GcQLjLu6GT4GdyAIRgLVO4sdq488eirCMLXSi5QwDdtP1zOimEy0M/vRLtmntZrDTUNb esXENS4sNUqYYYzReHWhNNmel31s3SyO7MKwzhfS865zBNkAGBPeh96UVy1zDx7vbin2 /WDfntdI3q7Wcw1QgUzx0FRHCvkCd/5aSkvjm42vdEJq6Z2Fp6FEYkHynjDt0dP9Zfo4 KYB8HOqSlwx+ZtdRr7Re9axlKmaex9D3/fMGgI+ZBxNDVMpDnCNvOoK1b0SDaQ2D/LLg cYTQ== X-Gm-Message-State: AOAM532nlcBQgqviT+JAcu0t7XftiQlwJG1fXdWyv9olu90v1wrkIPc5 4j7Sy1jzrnPo5Ro6dZKZW03S9w== X-Google-Smtp-Source: ABdhPJyOyF9wWfauAE59YnbOyJwYqFYAmT+C3XLQZ8NncYYCmkw0OS1bL4ZQfw7qqScQqcZUkl025g== X-Received: by 2002:a05:6870:b023:b0:db:78e:7197 with SMTP id y35-20020a056870b02300b000db078e7197mr2135132oae.36.1651263509453; Fri, 29 Apr 2022 13:18:29 -0700 (PDT) Received: from localhost ([181.97.174.128]) by smtp.gmail.com with ESMTPSA id i6-20020a9d6506000000b0060603221255sm84923otl.37.2022.04.29.13.18.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 29 Apr 2022 13:18:29 -0700 (PDT) From: Martin Fernandez To: linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org, platform-driver-x86@vger.kernel.org, linux-mm@kvack.org Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, ardb@kernel.org, dvhart@infradead.org, andy@infradead.org, gregkh@linuxfoundation.org, rafael@kernel.org, rppt@kernel.org, akpm@linux-foundation.org, daniel.gutson@eclypsium.com, hughsient@gmail.com, alex.bazhaniuk@eclypsium.com, alison.schofield@intel.com, keescook@chromium.org, Martin Fernandez Subject: [PATCH v8 7/8] x86/efi: Mark e820_entries as crypto capable from EFI memmap Date: Fri, 29 Apr 2022 17:17:16 -0300 Message-Id: <20220429201717.1946178-8-martin.fernandez@eclypsium.com> X-Mailer: git-send-email 2.30.2 In-Reply-To: <20220429201717.1946178-1-martin.fernandez@eclypsium.com> References: <20220429201717.1946178-1-martin.fernandez@eclypsium.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-efi@vger.kernel.org Add a function to iterate over the EFI Memory Map and mark the regions tagged with EFI_MEMORY_CPU_CRYPTO in the e820_table; and call it from efi_init if add_efi_memmap is disabled. Also modify do_add_efi_memmap to mark the regions there. If add_efi_memmap is false, also check that the e820_table has enough size to (possibly) store also the EFI memmap. Signed-off-by: Martin Fernandez --- arch/x86/platform/efi/efi.c | 37 +++++++++++++++++++++++++++++++++++++ 1 file changed, 37 insertions(+) diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c index 147c30a81f15..3efa1c620c75 100644 --- a/arch/x86/platform/efi/efi.c +++ b/arch/x86/platform/efi/efi.c @@ -184,6 +184,8 @@ static void __init do_add_efi_memmap(void) } e820__range_add(start, size, e820_type); + if (md->attribute & EFI_MEMORY_CPU_CRYPTO) + e820__range_set_crypto_capable(start, size); } e820__update_table(e820_table); } @@ -441,6 +443,34 @@ static int __init efi_config_init(const efi_config_table_type_t *arch_tables) return ret; } +static void __init efi_mark_e820_regions_as_crypto_capable(void) +{ + efi_memory_desc_t *md; + + /* + * Calling e820__range_set_crypto_capable several times + * creates a bunch of entries in the E820 table. They probably + * will get merged when calling update_table but we need the + * space there anyway + */ + if (efi.memmap.nr_map + e820_table->nr_entries >= E820_MAX_ENTRIES) { + pr_err_once("E820 table is not large enough to fit EFI memmap; not marking entries as crypto capable\n"); + return; + } + + for_each_efi_memory_desc(md) { + if (md->attribute & EFI_MEMORY_CPU_CRYPTO) + e820__range_set_crypto_capable(md->phys_addr, + md->num_pages << EFI_PAGE_SHIFT); + } + + /* + * We added and modified regions so it's good to update the + * table to merge/sort + */ + e820__update_table(e820_table); +} + void __init efi_init(void) { if (IS_ENABLED(CONFIG_X86_32) && @@ -494,6 +524,13 @@ void __init efi_init(void) set_bit(EFI_RUNTIME_SERVICES, &efi.flags); efi_clean_memmap(); + /* + * If add_efi_memmap then there is no need to mark the regions + * again + */ + if (!add_efi_memmap) + efi_mark_e820_regions_as_crypto_capable(); + if (efi_enabled(EFI_DBG)) efi_print_memmap(); } From patchwork Fri Apr 29 20:17:17 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Martin Fernandez X-Patchwork-Id: 567600 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 A6127C433FE for ; Fri, 29 Apr 2022 20:18:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1380686AbiD2UWC (ORCPT ); Fri, 29 Apr 2022 16:22:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52544 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1380648AbiD2UV5 (ORCPT ); Fri, 29 Apr 2022 16:21:57 -0400 Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BB3A0D5E95 for ; Fri, 29 Apr 2022 13:18:37 -0700 (PDT) Received: by mail-ot1-x331.google.com with SMTP id k25-20020a056830169900b00605f215e55dso2504042otr.13 for ; Fri, 29 Apr 2022 13:18:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eclypsium.com; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=OkG/F7+kBMNIWCowVtEazmyHhBwO2DxtbJbfhKP712A=; b=CFVomb+9tyTJtBjEhdpiH1zhwooGhEZao10gTFdxqakjE50a70JiLTBnTH7LkExN+V oc+UNf8vfz0q7LVdjvbwtCy8BnniQSsjA83H+fwEwh99U6UXRuClAcfUpV3bpAAc9umN hs0O4wqgUFbbSCgB/tJAtF1o+ndijINfhWVCNdR3bBValgZ8Z1AMvT3jzPCO56a+EUVj eQw67Azpa5Iv4+Ywhr9kjCjFBO3QXN4+XwHcJopDuXewZTbZD9+wbmGww65HIywNbytB K9o9k/DmPxRb4TRXsls4NQStEslTiFL+j1mwuEZbxJ6bjwWQEk+zv+NX6GgbMX2SInsf YuNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=OkG/F7+kBMNIWCowVtEazmyHhBwO2DxtbJbfhKP712A=; b=biVGX+TJjmQDyvl4WDw7rW6RiFinIkmd/EX8N7LWH8P2e+9bqzLPYldY7Eg/hU4YC+ 6iN378zfAJpZfwmCRHhtVPUVyUoTjCAqGV/iOQCIMsiDmQwlbBiHlJhr8rJxPYr27w6M /MgI2ElNyjJmgWUub7BFROkV2rHHgYizm43FgC2j5eV3vEjUAVrxedpN0/L4oy3qcpYa qzVD8Het8N1rT2ZeOYslDKxeOFnQoyPnKrJef9YnGB5MK99N0pHIfIhRSxkuFfm33/GC QvH8utCDBkt+b4Q/3Z0qL4MilUl0i/Ym7DeJqW1MzCo3886khjdOowQz932YDfmFX1sM z7aQ== X-Gm-Message-State: AOAM530g+g/fBxTHP6F+Y4pi6dNEjxacXbGkKY/kaeULVH45Scfa20j3 jMEQq9hjplm7jGGZpyo4GchXtA== X-Google-Smtp-Source: ABdhPJwfcMjRvkAXKIDIz9yJyzv/MGd9Qc+uZBZYcbTg+2X+d01VGqB1uGOCZg191g8uEunpkZerYw== X-Received: by 2002:a9d:37cb:0:b0:5cc:7a51:c984 with SMTP id x69-20020a9d37cb000000b005cc7a51c984mr409643otb.98.1651263517007; Fri, 29 Apr 2022 13:18:37 -0700 (PDT) Received: from localhost ([181.97.174.128]) by smtp.gmail.com with ESMTPSA id t13-20020a05683014cd00b0060603221245sm79060otq.21.2022.04.29.13.18.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 29 Apr 2022 13:18:36 -0700 (PDT) From: Martin Fernandez To: linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org, platform-driver-x86@vger.kernel.org, linux-mm@kvack.org Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, ardb@kernel.org, dvhart@infradead.org, andy@infradead.org, gregkh@linuxfoundation.org, rafael@kernel.org, rppt@kernel.org, akpm@linux-foundation.org, daniel.gutson@eclypsium.com, hughsient@gmail.com, alex.bazhaniuk@eclypsium.com, alison.schofield@intel.com, keescook@chromium.org, Martin Fernandez Subject: [PATCH v8 8/8] drivers/node: Show in sysfs node's crypto capabilities Date: Fri, 29 Apr 2022 17:17:17 -0300 Message-Id: <20220429201717.1946178-9-martin.fernandez@eclypsium.com> X-Mailer: git-send-email 2.30.2 In-Reply-To: <20220429201717.1946178-1-martin.fernandez@eclypsium.com> References: <20220429201717.1946178-1-martin.fernandez@eclypsium.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-efi@vger.kernel.org Show in each node in sysfs if its memory is able to do be encrypted by the CPU; on EFI systems: if all its memory is marked with EFI_MEMORY_CPU_CRYPTO in the EFI memory map. Signed-off-by: Martin Fernandez --- Documentation/ABI/testing/sysfs-devices-node | 10 ++++++++++ drivers/base/node.c | 10 ++++++++++ 2 files changed, 20 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-devices-node diff --git a/Documentation/ABI/testing/sysfs-devices-node b/Documentation/ABI/testing/sysfs-devices-node new file mode 100644 index 000000000000..0e95420bd7c5 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-devices-node @@ -0,0 +1,10 @@ +What: /sys/devices/system/node/nodeX/crypto_capable +Date: April 2022 +Contact: Martin Fernandez +Users: fwupd (https://fwupd.org) +Description: + This value is 1 if all system memory in this node is + capable of being protected with the CPU's memory + cryptographic capabilities. It is 0 otherwise. + On EFI systems the node will be marked with + EFI_MEMORY_CPU_CRYPTO. \ No newline at end of file diff --git a/drivers/base/node.c b/drivers/base/node.c index ec8bb24a5a22..1df15ea03c27 100644 --- a/drivers/base/node.c +++ b/drivers/base/node.c @@ -560,11 +560,21 @@ static ssize_t node_read_distance(struct device *dev, } static DEVICE_ATTR(distance, 0444, node_read_distance, NULL); +static ssize_t crypto_capable_show(struct device *dev, + struct device_attribute *attr, char *buf) +{ + struct pglist_data *pgdat = NODE_DATA(dev->id); + + return sysfs_emit(buf, "%d\n", pgdat->crypto_capable); +} +static DEVICE_ATTR_RO(crypto_capable); + static struct attribute *node_dev_attrs[] = { &dev_attr_meminfo.attr, &dev_attr_numastat.attr, &dev_attr_distance.attr, &dev_attr_vmstat.attr, + &dev_attr_crypto_capable.attr, NULL };