Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp5066261rwd; Tue, 23 May 2023 17:49:47 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ7APBXC4HtdlE+7Va6kISPhXC4N3ruuMdjWtJKpZ3veLHl7n47XSQ177eM18jVpSM4SUmPZ X-Received: by 2002:a17:90a:f0d5:b0:250:7d1f:938b with SMTP id fa21-20020a17090af0d500b002507d1f938bmr15506767pjb.23.1684889387189; Tue, 23 May 2023 17:49:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1684889387; cv=none; d=google.com; s=arc-20160816; b=m1e77jG7tsaLQPVjOJujGEuyhQFg363JSyUbjiWmMIFfjZTImEBSvYwdRvkCehav7r Uqk58ikGB5oEvVOdj4MtMS0QmUY+SPoDguEEcQvVlafj4hT+hTE4mdPFISV18JtdeBB7 SPTj4WQW4Mom6jueFub5t8ZU8CdZSGK5zWNj/QZ02V9HFDtpqbzxzG/sONnpqPECGebl KgXMvGvTZuv6M//Uxf5HNjz5qRmoUq02YTAn1RdSC8YqsE1nqItBW3EoMWymQFP85pu8 3V0H0okC6WEVCFrVDDvRtMqJ8lD46d239pQ+MrViE5mzkYuaf5oyWuh/DDcxH44mMUlO nHFQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:references:message-id:in-reply-to :subject:cc:to:from:date:dkim-signature; bh=nb1HZAA6jWswrdHpi2mE5EOlqvUJPG125mFoOv5VQGI=; b=gLBp6bUPFqUr/xlhUKxkD+bo+hy3BzE/+A+7rgTZOaa9P0Afdtm6IXw/VuhSzyt5Dn 5FjwF/OEi9Q0jLxWSMSKfB8RUEXJvVTUtdYQ1WGbxMCVjfXhdnZOFIWPigYrhDfPlTSK TafSbo4M1sQC1KGq3aoBg8BkUorj/ZbCqYYD9rGSKoBj4gImh8ZKFVyfstRY/K61Pbpl HN/kdgdyNHKk9pVPNKxdgEXVmdjZuoeLAps1Fu5G8PSa+Fb4bhR1/6iG0jAw2zoHCoX9 WgWxXJjLSKjLHh1/BOiQ51A0MtmYMvo2X6bO+m/qFMxz1T6hwQyFTnRYt3fNo/0C17bP xt0g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20221208 header.b=obMsE1lX; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id e16-20020a17090a9a9000b0024e24699dfdsi301000pjp.78.2023.05.23.17.49.08; Tue, 23 May 2023 17:49:47 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20221208 header.b=obMsE1lX; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229498AbjEXAbv (ORCPT + 99 others); Tue, 23 May 2023 20:31:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44730 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229487AbjEXAbu (ORCPT ); Tue, 23 May 2023 20:31:50 -0400 Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 09A4EB5 for ; Tue, 23 May 2023 17:31:49 -0700 (PDT) Received: by mail-pl1-x636.google.com with SMTP id d9443c01a7336-1ae3f74c98bso6935ad.1 for ; Tue, 23 May 2023 17:31:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1684888308; x=1687480308; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:from:to:cc:subject:date:message-id:reply-to; bh=nb1HZAA6jWswrdHpi2mE5EOlqvUJPG125mFoOv5VQGI=; b=obMsE1lXozS/NM5Qr9t8zyy79IfRikzy9mErrcu9WXXIVCZGHrCglfhMRk5/M6Ve7j NZ/J26DbkEfGkW3lDfkwM9Jw80q4ANP1ezaNghYYTTlMzhZhxv3IlwUVNyTp/Tec7FDg kgN9XZPGqSp9oQXreB2xmD1ImQ8ZV1lGV7sj7H78Jo7zet9bW+MreTtlT4/q+YGyhBeF ROOmQ5yWPG/jEgB/u8vPcSBFN/YdrrFcaxrWAyTDynJD6Fr7l1Y3QW9iVtMjfu1iw4dN uUJ0Yla0/jkxpPlcYYNCz0xnCAvrKKiNWaDNEBtXBaX0bAeJw3zh3BqKiqaaLtc1UlUn y4/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684888308; x=1687480308; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=nb1HZAA6jWswrdHpi2mE5EOlqvUJPG125mFoOv5VQGI=; b=RaH0IN4fph/Xe0QstKc/DEknCRflg8zLODr0FsLgOntWnGTwN0fWCKFxANKBwTGBqf Nlq2omL/zuTwVKZk3DStFI14pVl+Nzta7GlndElVGJJAnVKCeHHVxqNtnSpq40B8Kv9f Vx2eBVQTWXiOAEkXPi79y5knPNnI9VArRhwuDYn55bKucPgPVT3mjtod1Zn5zcu9rBOW iqOHkT8SPwUIyWagwFH/5h98T8zoouX0i6zlzNBr8L2PJ48h2uN2/+v54YsgZEmpfBpI z9qoK9YGnI9ckxySRWqTFH2bxAyE/YFY4y3Rb1dC8PGGgMJhDXacu59ifBjOKBYPMmNG yW0Q== X-Gm-Message-State: AC+VfDywUkWkXtFKcXKfwH3X2qO+OV396ry3YxpdS0f5023FyuW5ZnxS CGZ5i8/w8X0UNw3ZIcPhGRciZw== X-Received: by 2002:a17:903:32cc:b0:1ac:3605:97dc with SMTP id i12-20020a17090332cc00b001ac360597dcmr130255plr.6.1684888308364; Tue, 23 May 2023 17:31:48 -0700 (PDT) Received: from [2620:0:1008:11:c789:c1fb:6667:1766] ([2620:0:1008:11:c789:c1fb:6667:1766]) by smtp.gmail.com with ESMTPSA id e3-20020a62ee03000000b0063d375ca0cbsm6210189pfi.151.2023.05.23.17.31.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 23 May 2023 17:31:47 -0700 (PDT) Date: Tue, 23 May 2023 17:31:47 -0700 (PDT) From: David Rientjes To: Kees Cook cc: David Hildenbrand , Lorenzo Stoakes , Vlastimil Babka , Christoph Lameter , Pekka Enberg , Joonsoo Kim , Roman Gushchin , Hyeonggon Yoo <42.hyeyoo@gmail.com>, linux-mm@kvack.org, linux-hardening@vger.kernel.org, patches@lists.linux.dev, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm/slab: remove HAVE_HARDENED_USERCOPY_ALLOCATOR In-Reply-To: <202305231001.08BC6058@keescook> Message-ID: <7a16b351-c7f6-b6a3-869b-5163c0d0793f@google.com> References: <20230523073136.4900-1-vbabka@suse.cz> <310077ed-6f3f-41fe-afcf-36500a9408ec@lucifer.local> <623a87c6-c0d2-799a-c39e-0d14dcdfa6df@suse.cz> <202305231001.08BC6058@keescook> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 23 May 2023, Kees Cook wrote: > On Tue, May 23, 2023 at 10:14:24AM +0200, David Hildenbrand wrote: > > On 23.05.23 09:56, Lorenzo Stoakes wrote: > > > On Tue, May 23, 2023 at 09:46:46AM +0200, Vlastimil Babka wrote: > > > > On 5/23/23 09:42, Lorenzo Stoakes wrote: > > > > > On Tue, May 23, 2023 at 09:31:36AM +0200, Vlastimil Babka wrote: > > > > > > With SLOB removed, both remaining allocators support hardened usercopy, > > > > > > so remove the config and associated #ifdef. > > > > > > > > > > > > Signed-off-by: Vlastimil Babka > > > > > > --- > > > > > > mm/Kconfig | 2 -- > > > > > > mm/slab.h | 9 --------- > > > > > > security/Kconfig | 8 -------- > > > > > > 3 files changed, 19 deletions(-) > > > > > > > > > > > > diff --git a/mm/Kconfig b/mm/Kconfig > > > > > > index 7672a22647b4..041f0da42f2b 100644 > > > > > > --- a/mm/Kconfig > > > > > > +++ b/mm/Kconfig > > > > > > @@ -221,7 +221,6 @@ choice > > > > > > config SLAB > > > > > > bool "SLAB" > > > > > > depends on !PREEMPT_RT > > > > > > - select HAVE_HARDENED_USERCOPY_ALLOCATOR > > > > > > help > > > > > > The regular slab allocator that is established and known to work > > > > > > well in all environments. It organizes cache hot objects in > > > > > > @@ -229,7 +228,6 @@ config SLAB > > > > > > > > > > > > config SLUB > > > > > > bool "SLUB (Unqueued Allocator)" > > > > > > - select HAVE_HARDENED_USERCOPY_ALLOCATOR > > > > > > help > > > > > > SLUB is a slab allocator that minimizes cache line usage > > > > > > instead of managing queues of cached objects (SLAB approach). > > > > > > diff --git a/mm/slab.h b/mm/slab.h > > > > > > index f01ac256a8f5..695ef96b4b5b 100644 > > > > > > --- a/mm/slab.h > > > > > > +++ b/mm/slab.h > > > > > > @@ -832,17 +832,8 @@ struct kmem_obj_info { > > > > > > void __kmem_obj_info(struct kmem_obj_info *kpp, void *object, struct slab *slab); > > > > > > #endif > > > > > > > > > > > > -#ifdef CONFIG_HAVE_HARDENED_USERCOPY_ALLOCATOR > > > > > > void __check_heap_object(const void *ptr, unsigned long n, > > > > > > const struct slab *slab, bool to_user); > > > > > > -#else > > > > > > -static inline > > > > > > -void __check_heap_object(const void *ptr, unsigned long n, > > > > > > - const struct slab *slab, bool to_user) > > > > > > -{ > > > > > > -} > > > > > > -#endif > > > > > > > > > > Hm, this is still defined in slab.c/slub.c and invoked in usercopy.c, do we > > > > > not want the prototype? > > > > > > > > Well I didn't delete the prototype, just the ifdef/else around, so now it's > > > > there unconditionally. > > > > > > > > > Perhaps replacing with #ifdef > > > > > CONFIG_HARDENED_USERCOPY instead? I may be missing something here :) > > > > > > > > Putting it under that #ifdef would work and match that the implementations > > > > of that function are under that same ifdef, but maybe it's unnecessary noise > > > > in the header? > > > > > > > > > > Yeah my brain inserted extra '-'s there, sorry! > > > > > > Given we only define __check_heap_object() in sl[au]b.c if > > > CONFIG_HARDENED_USERCOPY wouldn't we need to keep the empty version around > > > if !CONFIG_HARDENED_USERCOPY since check_heap_object() appears to be called > > > unconditionally? > > > > > > > The file is only compiled with CONFIG_HARDENED_USERCOPY: > > > > mm/Makefile:obj-$(CONFIG_HARDENED_USERCOPY) += usercopy.o > > Right. > > > Reviewed-by: David Hildenbrand > > Thanks! > > Reviewed-by: Kees Cook > Acked-by: David Rientjes