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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 70F08C7EE29 for ; Wed, 24 May 2023 00:31:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D7DCE900004; Tue, 23 May 2023 20:31:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D0560900002; Tue, 23 May 2023 20:31:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B5845900004; Tue, 23 May 2023 20:31:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 9F2E7900002 for ; Tue, 23 May 2023 20:31:51 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 66ABDAD7D7 for ; Wed, 24 May 2023 00:31:51 +0000 (UTC) X-FDA: 80823270822.14.4D41184 Received: from mail-pl1-f181.google.com (mail-pl1-f181.google.com [209.85.214.181]) by imf26.hostedemail.com (Postfix) with ESMTP id 907D8140017 for ; Wed, 24 May 2023 00:31:49 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=obMsE1lX; spf=pass (imf26.hostedemail.com: domain of rientjes@google.com designates 209.85.214.181 as permitted sender) smtp.mailfrom=rientjes@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1684888309; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=nb1HZAA6jWswrdHpi2mE5EOlqvUJPG125mFoOv5VQGI=; b=BPQGbdcexbWpa7RHLg4ImgrbBoTyvNBK0/HmGnem+llfD8LBk3svacwjJzi/C0/jtEvAs5 68IIWzFcpKaANMC7cgzUvViKJMevzAlwDT3EZF2aH0SfztmMll6GUiBnBCelG2WwoZ2hdr r07gHyroRrRwB5rta2blzBSSQbw8OpY= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684888309; a=rsa-sha256; cv=none; b=0Pwfl67xzDkanPMjVR3wWnNdyOWLrjWfzIIdJLisi4xt2PYStXB/w52mMuRCqchkY7RdZU PDcJA8czzpY/mMm6q0aqSydtcrGhtfphg0c1aUR/GBsMOAFxQPWNMHJ6nqB9IOy66kTqrq KwwNgQlSvXugtOxhQobyAuza1TmHlNs= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=obMsE1lX; spf=pass (imf26.hostedemail.com: domain of rientjes@google.com designates 209.85.214.181 as permitted sender) smtp.mailfrom=rientjes@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-pl1-f181.google.com with SMTP id d9443c01a7336-1ac65ab7432so8575ad.0 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=Q9fmFSAlIHybSHN64enuQNsbHi/8uoxMflKluIdRII6oq2XdKaroA68e1ejDeBP9gA kTLWa4Mo03pywT7U+KqSmxneW1mStUfKjQGfB8nKRdF8q1zCeKq3cViN17KT/+qT0YI+ UC2tNDWweZA9te+LYiLAKijz84D27fpnFVXq2aZ9fNuxevl4ndwHiGH2MYgz5DX70L6h 5Hwf3HsHoVwTFy8KnnCq7VuX1LOfdvt/JYpSfJhpTi2FYvkWX9fCiqGeFpwnp/XDcjSF SmvrBvfMAP+ZdyqtY2aJp9AceCq7qXQi+7/kSVrN96dPrij2qErExdjtn3mKcKHGkvfx /nGQ== X-Gm-Message-State: AC+VfDwfrcjMzaChciq6SsoHduCpDCrO9NNn3jPrLgmak9Jl5KCjdfvQ rIktlTOM9Ube5RL8nKwVbVznFA== X-Google-Smtp-Source: ACHHUZ6+2kjBpeHmmZzzLWonq9l7bPF0sHuH1f2qZtQExMnhCCqp5na25bJ31vG9eFZdE/w5T/SCCw== 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-Stat-Signature: cyifrumsk8741gf9ibqkzjpdwzjtzdgg X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 907D8140017 X-Rspam-User: X-HE-Tag: 1684888309-673269 X-HE-Meta: U2FsdGVkX19H1T2LiJEU0IzBMZTV8SetLB7dT2RAiVr4ffNuK3dxS9w52lTLZz43PIPk9wOJnt1uEOqh6YOy/mLOWAp7qc7SXhzT9tS9bsLOdkwBdXFScW2WvIiOeQKyBZOxoPB+1DpqDo0kUIssIH0WsPQqvGsCoV1tG/3wHLxzTgri7waiR8N5oq2dXfWa+HGk7lp3Y4/JlFaFvLmRMlyuoO4zu5uEwFIey+JxNgaFz6b1G2fVCN3pdTBEnt4IcS+Lm0gAQgeCSJX6JkyLvrViyTGDcwy5kL74re41eWVUDagCZdPNmsPAwccf3lrfr5/UM7FCGfNdNV9xyU1FdxvbGCUV6Nt+aK9TZp+8gK5DUd8Xm6nYHF9FUVjdxBdWqe5IVPRnluhaj5QcCNnwLs4Sdr7NiqAY8rgNFa6cL/RxrUGPLiq+CBuc7I1e+4Vin81w5bwdYFp3wznkhEDtIdt/A3SOR3lsnvBBNvCAuCwGYoBVMGKSPPcrNebbay7Jb7LRLozqkJS5RLW5wvfpeGBRg9rHwfVN0MI3YflVFMiVwu4bWFjStc1AsC9xCodnGQzRsR6O9m9Al7BPt2ONUBeqbDQhCQPoCKfVSx88tVpAUlpeb34VEMkNBXqOG6M1wQMIV801FIJhjuCV8SN7izuJjO0k4u0+HSqfjhYv4NbJXGggU9lxSOKGaB0P8uTI5vZ01RtxZQkWfWvkOI25XxCRA4eAbIqSskezwk1xU5oXdTNinTucw8+3o0/QwsLRdWSXfu+giSyeybnAc+1xxUSad412X4jF82VXWweV821hsGq4EgO0QOOcisfHpS/oG6zSEz4yHzYV2o7Vf2Dcq7yl+y5fKaUv/euTkhBqBN4NxmkTjzaUDI96FKp5XZTYkll83x3bg3Ix5yhJ4GLJuoLIvSPMm31j/7GWgBIiXBhGd/yOgFcQ4LSS9xOnAcCKlZKMw7DEToz6f9Br5Gw UirCNdDF BkvHaQUKYEAMPNgZoUPfdUUuFC6PlJGm0MNLXC0dtxMDLflpsZxMMlTHFutYMH0p28VMskN2Lix1kPfa1+d8y0o6LVno4YWmO2aKh1KZ4NXHU4CP2/o1xPvE6n3AL8K/UqmrNx18ha4YRf0bZ9EM3J/QceZcZNz4f9QMLhCsAnJ4RBNlbEJIq02sHpHzva/82C3TBzzmpJUVmfc5XRKgj7JWJQUo0p36sAcNrRXk0k78YbirAsFefmUmOT8UcFtFGTCQ0PyGk3CK8W/QR+RyTyJlvkYivjbc0N/2kVGYEMi55S5JP4x60ZeJGMN3+B/l1jM2IvxzACdq0gHclLKtfAe3BJET0ZPJKNPpy+PHD2R9sGLpFy1+QoR8Z4JzR/e880n5KR844KSnjhwG2aqz4K7TT/c20nil6O81KNZ5fTnEBK7d1WaZF2BY9Oba8HzDryUZd65YMndPpN4iMEvmhKxRKXZN6JWxFzoqTLzK/Abs2/iMrTqR/ixIj67KPF4XIjAFbP5wedG56+BK5nIWx2pG8Cvxu9yq9Lr0xYNvarwszE+We01kk6ttYKVaBMPyWezUYlwfeuvq63bwFfcPnLPXQig== 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: 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