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 X-Spam-Level: X-Spam-Status: No, score=-7.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY autolearn=no 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 E3FC5C433F5 for ; Mon, 20 Sep 2021 18:23:04 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 8A51961A83 for ; Mon, 20 Sep 2021 18:23:04 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 8A51961A83 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chromium.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id A92ED6B0071; Mon, 20 Sep 2021 14:23:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A43176B0072; Mon, 20 Sep 2021 14:23:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8E28D6B0073; Mon, 20 Sep 2021 14:23:03 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0126.hostedemail.com [216.40.44.126]) by kanga.kvack.org (Postfix) with ESMTP id 7AED46B0071 for ; Mon, 20 Sep 2021 14:23:03 -0400 (EDT) Received: from smtpin38.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 3273182499A8 for ; Mon, 20 Sep 2021 18:23:03 +0000 (UTC) X-FDA: 78608773446.38.00408DB Received: from mail-oo1-f47.google.com (mail-oo1-f47.google.com [209.85.161.47]) by imf24.hostedemail.com (Postfix) with ESMTP id DAB2DB0000BE for ; Mon, 20 Sep 2021 18:23:02 +0000 (UTC) Received: by mail-oo1-f47.google.com with SMTP id g4-20020a4ab044000000b002900bf3b03fso6178490oon.1 for ; Mon, 20 Sep 2021 11:23:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:in-reply-to:references:from:user-agent:date:message-id :subject:to:cc; bh=tUl0N7JwVVzwh8vmJFHcen+ugTff4BJQWnKbA8C2sGQ=; b=WL7KTgSgQdD4mWA/uxOomR2ggibcvCU/Jf/KkqFuVK3lDZhansu3cwyn1bhzND4EqI ZdSH+RDpeGG9YhS8XhFcP7w5ClIUE9dgoLHcihi0c7ERmcxeKLtVFYHyBvKqE3A5zcmK D4t59cyRsA/SaOAXKKERjcAsi5CVVE6i3NHVg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:in-reply-to:references:from :user-agent:date:message-id:subject:to:cc; bh=tUl0N7JwVVzwh8vmJFHcen+ugTff4BJQWnKbA8C2sGQ=; b=f+M6NRi5w1DiIP3x4qnPMlQEfK3xCVgUInEhQD+Ao0/43SZzOWv/IkbCOj1reH1gmY F+jUopl3kri39oH3zHq/HDorexIPfu3rjjSLA4QzFdt0E4HMRM8oxlG01urzXcuFYAyu rsNdq19S6zdjEMM1LzPNzqDSQHA5Zi2ep9XvE5h5OeBrmVmsAge8gSr2RHDNX1d1lEOj jwfRsFN8sbKL/yhSoZCWB2MbtXmIOhS0SgY2UW5TlF6fysfxxHME2KbNcRd921c/Nfc6 J60Fy90WCNFY8ZmkHubtN6QPDQSj8RKeYrNpAFEq40ZhZZ+03Dcx0uq+BHKpUn8I0Q9a cetw== X-Gm-Message-State: AOAM531flgP1sHD6g51unTiTcRrncppeXZ336yan9Wo4HEug6ud4E5sd QcPGIWHtQDVfgGAnDWeaCY0sSpmWOWKIc4nJIfihbQ== X-Google-Smtp-Source: ABdhPJxePw3aN2/L9BQ+Z8QzkjjkGEoHTnunl3+blHjNgWcCGnoaLJb4mRGBhIkGow8ZsudDBW4V9noBFI73pNQvHLo= X-Received: by 2002:a4a:c3c2:: with SMTP id e2mr7906145ooq.8.1632162182196; Mon, 20 Sep 2021 11:23:02 -0700 (PDT) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Mon, 20 Sep 2021 11:23:01 -0700 MIME-Version: 1.0 In-Reply-To: <202109200726.2EFEDC5@keescook> References: <20210601182202.3011020-1-swboyd@chromium.org> <20210601182202.3011020-5-swboyd@chromium.org> <202109200726.2EFEDC5@keescook> From: Stephen Boyd User-Agent: alot/0.9.1 Date: Mon, 20 Sep 2021 11:23:01 -0700 Message-ID: Subject: Re: [PATCH v3 4/4] slub: Force on no_hash_pointers when slub_debug is enabled To: Kees Cook Cc: Andrew Morton , linux-kernel@vger.kernel.org, Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Vlastimil Babka , linux-mm@kvack.org, Petr Mladek , Joe Perches Content-Type: text/plain; charset="UTF-8" X-Stat-Signature: 8osjua6zuohp8xjg7anqbofc9wo3eb6h Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=WL7KTgSg; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf24.hostedemail.com: domain of swboyd@chromium.org designates 209.85.161.47 as permitted sender) smtp.mailfrom=swboyd@chromium.org X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: DAB2DB0000BE X-HE-Tag: 1632162182-542363 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: Quoting Kees Cook (2021-09-20 07:29:54) > On Tue, Jun 01, 2021 at 11:22:02AM -0700, Stephen Boyd wrote: > > 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. > > Eeeek. I missed this patch. NAK NAK. People use slub_debug for > production systems to gain redzoning, etc, as a layer of defense, and > they absolutely do not want %p-hashing disabled. %p hashing is > controlled by the no_hash_pointers boot param (since v5.12), and needs to stay > separate from slub_debug. > > Can we please revert this in Linus's tree and in v5.14? > This is fine with me as long as debugging with slub_debug on the commandline is possible. Would you prefer v1 of this patch series[1] that uses the printk format to print unhashed pointers in slub debugging messages? [1] https://lore.kernel.org/r/20210520013539.3733631-1-swboyd@chromium.org