From patchwork Wed May 26 02:56:25 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Stephen Boyd X-Patchwork-Id: 12280547 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-16.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1EC5DC4707F for ; Wed, 26 May 2021 02:56:37 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id BF1C861090 for ; Wed, 26 May 2021 02:56:36 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BF1C861090 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chromium.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 0F5676B0072; Tue, 25 May 2021 22:56:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 05C826B0073; Tue, 25 May 2021 22:56:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D53776B0074; Tue, 25 May 2021 22:56:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0172.hostedemail.com [216.40.44.172]) by kanga.kvack.org (Postfix) with ESMTP id 7F6CD6B0072 for ; Tue, 25 May 2021 22:56:33 -0400 (EDT) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 24F17180AD830 for ; Wed, 26 May 2021 02:56:33 +0000 (UTC) X-FDA: 78181869066.11.2B122C7 Received: from mail-pf1-f173.google.com (mail-pf1-f173.google.com [209.85.210.173]) by imf23.hostedemail.com (Postfix) with ESMTP id 22ED0A0001C5 for ; Wed, 26 May 2021 02:56:27 +0000 (UTC) Received: by mail-pf1-f173.google.com with SMTP id p39so8794387pfw.8 for ; Tue, 25 May 2021 19:56:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=bid5eWeyAf/EDHZJqBvx8IkfWVIQDlnQOV7qBWhlldY=; b=YHUqpCGUaU3XGiG1Ugi9+sX324g45J0nlIN8TArCl5WEd2PdLVGMIeH6G1Yt996sq+ UJdg6ioHLzksl8pw795D9Vb6zf2cEXOM8B4go2oDXjRxZQAcFMdwH2zvNqmizJrxZZa6 9si9+9pgvOZWHvgTHo5bnyOExv1q/Y1kLfGPQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=bid5eWeyAf/EDHZJqBvx8IkfWVIQDlnQOV7qBWhlldY=; b=jUIK8ff92Ji0IKENx6un9YbmhWkarZgrgUBweeXdNbjOAEKxC5xaxvocOrGvUbqFtE D+wbQlA74ljF91kHnEg3Q/gkUIgBZycYxSfb6PbUmtr5NOhvbKH4Xz0CfhB/tDzgvomF 8M/1eFPlTGMHavGJ1dVq1CXo8M/M6AxEmWK7TKJ/pxXiMbjTMCXg1CnI5plAmWVXVlfL d1kyapBuYmiChrsu43g3BkSR4mVhK2aKkq8Q1/LYeets9+DEBmZ5cxaJdeM0FOccYhLH 4+DVQ73BpibS25/Fsy3hGWRQm01dqShbD/We/hoBO/w7cvxgcBwl3vhenqX/Nhf/6o6U Ww9w== X-Gm-Message-State: AOAM530Tkf2Hi0FFyuToLZZuArddBq3uVuF3sf2FfGdmtDh0DAyRkgsj Ki7KQl0CvvQzkiSQfDXeoeMvPw== X-Google-Smtp-Source: ABdhPJyv2XEnYPCYkiPG/atAIHMxyIZSy2O0IOFxWNkuHMQUjnM1/Z8UFarQXTAHQUcrudUKJj6e5A== X-Received: by 2002:a63:fd46:: with SMTP id m6mr5658896pgj.403.1621997792024; Tue, 25 May 2021 19:56:32 -0700 (PDT) Received: from smtp.gmail.com ([2620:15c:202:201:5a1b:e4e5:eb10:8870]) by smtp.gmail.com with ESMTPSA id 5sm2966295pjo.17.2021.05.25.19.56.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 25 May 2021 19:56:31 -0700 (PDT) From: Stephen Boyd To: Andrew Morton Cc: linux-kernel@vger.kernel.org, Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Vlastimil Babka , linux-mm@kvack.org, Petr Mladek , Joe Perches Subject: [PATCH v2 4/4] slub: Force on no_hash_pointers when slub_debug is enabled Date: Tue, 25 May 2021 19:56:25 -0700 Message-Id: <20210526025625.601023-5-swboyd@chromium.org> X-Mailer: git-send-email 2.31.1.818.g46aad6cb9e-goog In-Reply-To: <20210526025625.601023-1-swboyd@chromium.org> References: <20210526025625.601023-1-swboyd@chromium.org> MIME-Version: 1.0 Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=YHUqpCGU; spf=pass (imf23.hostedemail.com: domain of swboyd@chromium.org designates 209.85.210.173 as permitted sender) smtp.mailfrom=swboyd@chromium.org; dmarc=pass (policy=none) header.from=chromium.org X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 22ED0A0001C5 X-Stat-Signature: ysocz7f3sa4heczsw89s66ccnt3n3ow3 X-HE-Tag: 1621997787-265693 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Obscuring the pointers that slub shows when debugging makes for some confusing slub debug messages: Padding overwritten. 0x0000000079f0674a-0x000000000d4dce17 Those addresses are hashed for kernel security reasons. If we're trying to be secure with slub_debug on the commandline we have some big problems given that we dump whole chunks of kernel memory to the kernel logs. Let's force on the no_hash_pointers commandline flag when slub_debug is on the commandline. This makes slub debug messages more meaningful and if by chance a kernel address is in some slub debug object dump we will have a better chance of figuring out what went wrong. Note that we don't use %px in the slub code because we want to reduce the number of places that %px is used in the kernel. This also nicely prints a big fat warning at kernel boot if slub_debug is on the commandline so that we know that this kernel shouldn't be used on production systems. Signed-off-by: Stephen Boyd Reported-by: kernel test robot Reported-by: kernel test robot --- I opted for extern because I guess we don't want to advertise no_hash_pointers_enable() in some sort of header file? It can be put in a header file but I see that the no_hash_pointers variable is also not in a header file but exported as symbol. lib/vsprintf.c | 2 +- mm/slub.c | 6 ++++++ 2 files changed, 7 insertions(+), 1 deletion(-) diff --git a/lib/vsprintf.c b/lib/vsprintf.c index f0c35d9b65bf..cc281f5895f9 100644 --- a/lib/vsprintf.c +++ b/lib/vsprintf.c @@ -2186,7 +2186,7 @@ char *fwnode_string(char *buf, char *end, struct fwnode_handle *fwnode, bool no_hash_pointers __ro_after_init; EXPORT_SYMBOL_GPL(no_hash_pointers); -static int __init no_hash_pointers_enable(char *str) +int __init no_hash_pointers_enable(char *str) { if (no_hash_pointers) return 0; diff --git a/mm/slub.c b/mm/slub.c index bf4949115412..1c30436d3e6c 100644 --- a/mm/slub.c +++ b/mm/slub.c @@ -4451,6 +4451,8 @@ static struct kmem_cache * __init bootstrap(struct kmem_cache *static_cache) return s; } +extern int no_hash_pointers_enable(char *str); + void __init kmem_cache_init(void) { static __initdata struct kmem_cache boot_kmem_cache, @@ -4470,6 +4472,10 @@ void __init kmem_cache_init(void) for_each_node_state(node, N_NORMAL_MEMORY) node_set(node, slab_nodes); + /* Print slub debugging pointers without hashing */ + if (static_branch_unlikely(&slub_debug_enabled)) + no_hash_pointers_enable(NULL); + create_boot_cache(kmem_cache_node, "kmem_cache_node", sizeof(struct kmem_cache_node), SLAB_HWCACHE_ALIGN, 0, 0);