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 DCFF9EE4981 for ; Fri, 18 Aug 2023 17:56:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1379167AbjHRR4J (ORCPT ); Fri, 18 Aug 2023 13:56:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44740 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235112AbjHRRzq (ORCPT ); Fri, 18 Aug 2023 13:55:46 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 21EBA271B; Fri, 18 Aug 2023 10:55:45 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id AB37862952; Fri, 18 Aug 2023 17:55:44 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 251FBC433C8; Fri, 18 Aug 2023 17:55:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1692381344; bh=KONQ3xcRnoS4lAb+HMyH7HyVsHgReeRIXjIT4SA1idM=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=LiCZSUBAW80WQNaU36+qdHOShmUA4NduLKvtU+3U3wolKrrnJP6VYMIT9f+aaMWhK rloZUyqzQ5lrxYiHlDnT6pwL4rsw4o2AQ1ydrgH8OW5l7WYjLE5HLxYprkfW0o+yUm 9//vTI5ECw1kakPC+YBXBwCRn5iCMPWX/PY5QFs0= Date: Fri, 18 Aug 2023 10:55:42 -0700 From: Andrew Morton To: Kees Cook Cc: linux-hardening@vger.kernel.org, Elena Reshetova , David Windsor , Hans Liljestrand , Trond Myklebust , Anna Schumaker , Chuck Lever , Jeff Layton , Neil Brown , Olga Kornievskaia , Dai Ngo , Tom Talpey , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Sergey Senozhatsky , Alexey Gladkov , "Eric W. Biederman" , Yu Zhao , linux-kernel@vger.kernel.org, linux-nfs@vger.kernel.org, netdev@vger.kernel.org Subject: Re: [PATCH v2] creds: Convert cred.usage to refcount_t Message-Id: <20230818105542.a6b7c41c47d4c6b9ff2e8839@linux-foundation.org> In-Reply-To: <20230818041740.gonna.513-kees@kernel.org> References: <20230818041740.gonna.513-kees@kernel.org> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org On Thu, 17 Aug 2023 21:17:41 -0700 Kees Cook wrote: > From: Elena Reshetova > > atomic_t variables are currently used to implement reference counters > with the following properties: > - counter is initialized to 1 using atomic_set() > - a resource is freed upon counter reaching zero > - once counter reaches zero, its further > increments aren't allowed > - counter schema uses basic atomic operations > (set, inc, inc_not_zero, dec_and_test, etc.) > > Such atomic variables should be converted to a newly provided > refcount_t type and API that prevents accidental counter overflows and > underflows. This is important since overflows and underflows can lead > to use-after-free situation and be exploitable. ie, if we have bugs which we have no reason to believe presently exist, let's bloat and slow down the kernel just in case we add some in the future? Or something like that. dangnabbit, that refcount_t. x86_64 defconfig: before: text data bss dec hex filename 3869 552 8 4429 114d kernel/cred.o 6140 724 16 6880 1ae0 net/sunrpc/auth.o after: text data bss dec hex filename 4573 552 8 5133 140d kernel/cred.o 6236 724 16 6976 1b40 net/sunrpc/auth.o Please explain, in a non handwavy and non cargoculty fashion why this speed and space cost is justified.