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 10B0DC433EF for ; Mon, 20 Sep 2021 18:44:13 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id AA1DE606A5 for ; Mon, 20 Sep 2021 18:44:12 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org AA1DE606A5 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 3C6446B0071; Mon, 20 Sep 2021 14:44:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 34FA96B0072; Mon, 20 Sep 2021 14:44:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1EEDE900002; Mon, 20 Sep 2021 14:44:12 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0068.hostedemail.com [216.40.44.68]) by kanga.kvack.org (Postfix) with ESMTP id 0D0CF6B0071 for ; Mon, 20 Sep 2021 14:44:12 -0400 (EDT) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id A30DB180ACF6C for ; Mon, 20 Sep 2021 18:44:11 +0000 (UTC) X-FDA: 78608826702.28.39C8F11 Received: from mail-oi1-f178.google.com (mail-oi1-f178.google.com [209.85.167.178]) by imf17.hostedemail.com (Postfix) with ESMTP id 55CCCF000396 for ; Mon, 20 Sep 2021 18:44:11 +0000 (UTC) Received: by mail-oi1-f178.google.com with SMTP id 6so26080747oiy.8 for ; Mon, 20 Sep 2021 11:44:11 -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=YSVdlrDBVCVVyrsd5P+CkOqJiePqjs/Ib4JDP05yk6g=; b=ZsvwpP2v4ozbtgRIFQq2vJIcLOO1oeeC3S05lrMD/GKvbZ+S4hSMMmUSYMlVuhCjTo nVqPHY0QCuPSqvt2V+wHAawRZ59em5t9cZhdAxWSuX0oTRZzwLt8mZz49UDQgDV5MYwh xp/wPE1UkkV0oCf/ovgIZDgy7DMYX0bVKJr4k= 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=YSVdlrDBVCVVyrsd5P+CkOqJiePqjs/Ib4JDP05yk6g=; b=X7r3WhYdR1SkW0NxXCrTOnEyikzmk2SOYoOHP+3pmbhsQ2ls6z8lwm4Jq7VrOA+6Y5 Pxs1lgsc6BolkMizHMnSkhq+2A6tJJnN3v0ovH3Pdu4w5HEo9mOTXEI7oXKrp8gGW3Va o8UqpV3vDXBjcnpe9TMV8Ww2Yq0ROqK+2vyzOOt/u57EF7FeviZ/3Z9iz3JkwG+Nis3f Lxr7p7p0alhEDktX+E+klByAsuwINK0PzrgrXZf7C1tJHmJ7adiBAlGggc2nvsytieAL v/J7DmaJmbgmi3VpFqheEymUGYIjAFSg7eKkwAlNyH7Y4wL4SUSiXocZQJnbT3NSibxK 85jw== X-Gm-Message-State: AOAM533KB3VafXpB6mHVPtQV9DCFtkDpdZ37stsOwW7gdjWZTHlIjt54 lx0uWQ2iJpRarLufTwpYrp4Ar+5tceRS/dlzDSZGJQ== X-Google-Smtp-Source: ABdhPJzFA3kPFngWBaG5f8xc286I+bRBOt7JpKdDnUJEWKoyraQKD3YnKGLjm2TbXtlTjpItZRz8lboJA8EiJUhytoU= X-Received: by 2002:aca:3110:: with SMTP id x16mr422958oix.64.1632163450731; Mon, 20 Sep 2021 11:44:10 -0700 (PDT) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Mon, 20 Sep 2021 11:44:10 -0700 MIME-Version: 1.0 In-Reply-To: <202109201126.E9902480D9@keescook> References: <20210601182202.3011020-1-swboyd@chromium.org> <20210601182202.3011020-5-swboyd@chromium.org> <202109200726.2EFEDC5@keescook> <202109201126.E9902480D9@keescook> From: Stephen Boyd User-Agent: alot/0.9.1 Date: Mon, 20 Sep 2021 11:44:10 -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" Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=ZsvwpP2v; spf=pass (imf17.hostedemail.com: domain of swboyd@chromium.org designates 209.85.167.178 as permitted sender) smtp.mailfrom=swboyd@chromium.org; dmarc=pass (policy=none) header.from=chromium.org X-Stat-Signature: a6oec45yyhgjxzx7xr3qeuwams1ckqor X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 55CCCF000396 X-HE-Tag: 1632163451-435319 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 11:28:50) > On Mon, Sep 20, 2021 at 11:23:01AM -0700, Stephen Boyd wrote: > > 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 > > I'd like to keep %px use in the kernel minimized. Seeing full pointers (%p > hashing disabled) can be done with the no_hash_pointers boot param, and > that's used in other debug cases as well. I'd rather keep it a global > knob. > Can you elaborate on your use case where slub debugging is used for security in production systems via redzoning? Maybe that redzoning logic in slub debug should be moved out of CONFIG_SLUB_DEBUG into slub proper? Or maybe the config symbol should be changed to something that doesn't have 'debug' in the name? The main goal of this series was to make slub debug messages I saw useful instead of confusing given that all the pointers were hashed. If some part of slub debugging is production critical then I wonder why it's behind a debug named config knob and why it prints so much pointer information on production systems.