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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6694FC05027 for ; Thu, 9 Feb 2023 00:35:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229655AbjBIAfY (ORCPT ); Wed, 8 Feb 2023 19:35:24 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33272 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229510AbjBIAfW (ORCPT ); Wed, 8 Feb 2023 19:35:22 -0500 Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [IPv6:2607:f8b0:4864:20::1036]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D401D1042D for ; Wed, 8 Feb 2023 16:35:21 -0800 (PST) Received: by mail-pj1-x1036.google.com with SMTP id s89-20020a17090a2f6200b0023125ebb4b1so702474pjd.3 for ; Wed, 08 Feb 2023 16:35:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=in-reply-to:content-disposition:mime-version:references:subject:cc :to:from:date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=w3/tbsKAE6pHdBxaD3xoFp2iWmuueGZM8Ld1HBgpBx4=; b=TT7INl3UeTVm7i5ccOWOemNKA1TCJ56sZtnxxR4JLLKn1VTZ4dubReYPNA+0b1PIcP yJzQaguHkiTmZA3YRhyN7Q3ftZh1lXEGF6a5QoXz5S/I795cAFeBkusjPDLRiANeK06n 0FnyMhzulVrIBw73CXW/Y3YLxIXrdHEfAZIPE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:subject:cc :to:from:date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=w3/tbsKAE6pHdBxaD3xoFp2iWmuueGZM8Ld1HBgpBx4=; b=PvLpYqPVObdIg03FgBlFBbuyADXwxPiu85UishXdR4wrSj/D6dLGGBbj4/C1NQQlIw YB4q8FQFk/DyRWy2nl5XYtRVx/FRVd69zoNu+HjiNnxlOG8+ePlGw96pX0T52+f8lGv3 UvkS7me46Yp3aKI4uzgx94k/04sB+0cLZuik89vbthb/uG5F1uFBdHP6ng79TVUpa0B0 Ht5l7JZtvg6xxuHr3LZOKQZty2d64M90JVbgs+VsK7jX99ls/tCLpEfQrzc6xG4v6Nj9 5rU4GL3PTA9HrlNSGviUW7dNA8yIUOCb05+8amHrdk61q+GAOoRlQKCVmNUCl1LvNNCy 0z6g== X-Gm-Message-State: AO0yUKURnxfRuTjw7ZTBurhopeamOkmgZQ4DkFkhwW0H/Ijcb4oQHjMm 3+HLNYeykmkU7HGONyDV20RE9w== X-Google-Smtp-Source: AK7set+wKMq6T3qyb881FsIGkRTd5IAeXJrKAiit4gN6PbY0p0AdJjwp14n/PBLDuWVjxVDnkTuZSg== X-Received: by 2002:a17:902:e841:b0:196:2bf1:b690 with SMTP id t1-20020a170902e84100b001962bf1b690mr11005685plg.13.1675902921336; Wed, 08 Feb 2023 16:35:21 -0800 (PST) Received: from www.outflux.net (198-0-35-241-static.hfc.comcastbusiness.net. [198.0.35.241]) by smtp.gmail.com with ESMTPSA id jw14-20020a170903278e00b001743ba85d39sm64721plb.110.2023.02.08.16.35.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Feb 2023 16:35:20 -0800 (PST) Message-ID: <63e43fc8.170a0220.954a3.026d@mx.google.com> X-Google-Original-Message-ID: <202302081634.@keescook> Date: Wed, 8 Feb 2023 16:35:19 -0800 From: Kees Cook To: Hyeonggon Yoo <42.hyeyoo@gmail.com> Cc: Vlastimil Babka , Stephen Boyd , concord@gentoo.org, Pekka Enberg , David Rientjes , Joonsoo Kim , Petr Mladek , linux-mm@kvack.org, stable@vger.kernel.org, Steven Rostedt , Sergey Senozhatsky , Andy Shevchenko , Rasmus Villemoes , Christoph Lameter , Andrew Morton , Roman Gushchin , Keith Busch , Jens Axboe , Bart Van Assche , Mikulas Patocka , Ard Biesheuvel , Mark Rutland , linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org Subject: Re: [PATCH] Revert "slub: force on no_hash_pointers when slub_debug is enabled" References: <20230208194712.never.999-kees@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-hardening@vger.kernel.org On Wed, Feb 08, 2023 at 11:58:54PM +0000, Hyeonggon Yoo wrote: > On Wed, Feb 08, 2023 at 11:47:17AM -0800, Kees Cook wrote: > > This reverts commit 792702911f581f7793962fbeb99d5c3a1b28f4c3. > > > > Linking no_hash_pointers() to slub_debug has had a chilling effect > > on using slub_debug features for security hardening, since system > > builders are forced to choose between redzoning and heap address location > > exposures. Instead, just require that the "no_hash_pointers" boot param > > needs to be used to expose pointers during slub_debug reports. > > > > Cc: Vlastimil Babka > > Cc: Stephen Boyd > > Cc: concord@gentoo.org > > Cc: Pekka Enberg > > Cc: David Rientjes > > Cc: Joonsoo Kim > > Cc: Petr Mladek > > Cc: linux-mm@kvack.org > > Cc: stable@vger.kernel.org > > Link: https://lore.kernel.org/lkml/202109200726.2EFEDC5@keescook/ > > Signed-off-by: Kees Cook > > in the commit message: > > > 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. > > it dumps parts of kernel memory anyway and I'm not sure if slub_debug is > supposed to be used for security hardening. > > what about introducing new boot parameter like, slub_hardening, > which does not print anything? But it would be parsed for the same options? Redzoning, for example, is the common thing used for folks interested in detecting memory corruption attacks, etc. -- Kees Cook