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=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 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 5F2E1C433E0 for ; Tue, 2 Mar 2021 16:23:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 2FFA664F09 for ; Tue, 2 Mar 2021 16:23:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1379984AbhCBQJA (ORCPT ); Tue, 2 Mar 2021 11:09:00 -0500 Received: from mx2.suse.de ([195.135.220.15]:44624 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1376699AbhCBNij (ORCPT ); Tue, 2 Mar 2021 08:38:39 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 141C2ABF4; Tue, 2 Mar 2021 13:37:20 +0000 (UTC) To: Petr Mladek , Geert Uytterhoeven Cc: Marco Elver , Timur Tabi , Steven Rostedt , Sergey Senozhatsky , Andy Shevchenko , Matthew Wilcox , Andrew Morton , Linus Torvalds , roman.fietze@magna.com, Kees Cook , John Ogness , Akinobu Mita , Alexander Potapenko , Andrey Konovalov , Rasmus Villemoes , Pavel Machek , Tetsuo Handa , Linux Kernel Mailing List , Linux MM References: <20210214161348.369023-1-timur@kernel.org> <20210214161348.369023-4-timur@kernel.org> From: Vlastimil Babka Subject: Re: [PATCH 3/3] [v4] lib/vsprintf: no_hash_pointers prints all addresses as unhashed Message-ID: <8893ff08-1e50-316c-f632-cd37be1690d5@suse.cz> Date: Tue, 2 Mar 2021 14:37:19 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 3/2/21 2:29 PM, Petr Mladek wrote: > On Tue 2021-03-02 13:51:35, Geert Uytterhoeven wrote: >> > > > + >> > > > + pr_warn("**********************************************************\n"); >> > > > + pr_warn("** NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE **\n"); >> > > > + pr_warn("** **\n"); >> > > > + pr_warn("** This system shows unhashed kernel memory addresses **\n"); >> > > > + pr_warn("** via the console, logs, and other interfaces. This **\n"); >> > > > + pr_warn("** might reduce the security of your system. **\n"); >> > > > + pr_warn("** **\n"); >> > > > + pr_warn("** If you see this message and you are not debugging **\n"); >> > > > + pr_warn("** the kernel, report this immediately to your system **\n"); >> > > > + pr_warn("** administrator! **\n"); >> > > > + pr_warn("** **\n"); >> > > > + pr_warn("** NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE **\n"); >> > > > + pr_warn("**********************************************************\n"); >> > > > + >> > > > + return 0; >> > > > +} >> > > > +early_param("no_hash_pointers", no_hash_pointers_enable); >> > > >> > > While bloat-o-meter is not smart enough to notice the real size impact, >> > > this does add more than 500 bytes of string data to the kernel. >> > > Do we really need such a large message? >> > > Perhaps the whole no_hash_pointers machinery should be protected by >> > > "#ifdef CONFIG_DEBUG_KERNEL"? > > This was the deal. The configure option is a no-go, see below and also > https://lore.kernel.org/r/CAHk-=wgaK4cz=K-JB4p-KPXBV73m9bja2w1W1Lr3iu8+NEPk7A@mail.gmail.com I think it's a no-go only when enabling such option equals to "no_hash_pointers" being always passed. What Geert suggests is that you need both CONFIG_DEBUG_KERNEL *and* no_hash_pointers and that's different. >> > We recently stumbled across this, and it appears an increasing number >> > of production kernels enable CONFIG_DEBUG_KERNEL [1], so it likely >> > isn't the solution (we tried to use CONFIG_DEBUG_KERNEL in similar >> >> I guess the people who do care about kernel size do know to disable >> CONFIG_DEBUG_KERNEL, so it would help them. >> The everything-but-the-kitchen-sink distro people don't care about kernel >> size anyway. > > The problem with the configure option is not about size. The problem is > that there would be many kernels in the wild with this option enabled. > People would install them without knowing that they are less secure. Same as above. > Distros would need to provide both kernels. Well, they already do. > But it might be worse. Some distros might even want to enable it > by default. > > Also many bugs might be debugged without this option. Some bugs > are hard to reproduce and might be visible only on production > systems. It should be possible to enable this only when really > needed and the user must be aware of the risk. So this is basically a kernel tinyfication issue, right? Is that still pursued today? Are there better config options suitable for this than CONFIG_DEBUG_KERNEL? >> > Would placing the strings into an __initconst array help? >> >> That would indeed help to reduce run-time memory consumption. > > Sure. We could do this. Do you want to send a patch, please? > >> It would not solve the raw kernel size increase. > > I see. Well, the compression should be pretty efficient > for a text (with many spaces). > > Best Regards, > Petr >