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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 23BFDC433F5 for ; Mon, 25 Oct 2021 21:18:20 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id AF7CE60FDC for ; Mon, 25 Oct 2021 21:18:19 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org AF7CE60FDC Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 4858F940008; Mon, 25 Oct 2021 17:18:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4356A940007; Mon, 25 Oct 2021 17:18:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3259B940008; Mon, 25 Oct 2021 17:18:19 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0226.hostedemail.com [216.40.44.226]) by kanga.kvack.org (Postfix) with ESMTP id 229BE940007 for ; Mon, 25 Oct 2021 17:18:19 -0400 (EDT) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id CF8401801C382 for ; Mon, 25 Oct 2021 21:18:18 +0000 (UTC) X-FDA: 78736223076.24.799FC3F Received: from mail-lj1-f180.google.com (mail-lj1-f180.google.com [209.85.208.180]) by imf25.hostedemail.com (Postfix) with ESMTP id 9EDEEB000180 for ; Mon, 25 Oct 2021 21:18:12 +0000 (UTC) Received: by mail-lj1-f180.google.com with SMTP id w23so10864054lje.7 for ; Mon, 25 Oct 2021 14:18:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=C3OGKy4Xs7bfwbjubDC7Rewtx/I9W+4XjVnd2m5nUvo=; b=RBroiKM+cF4sG5ufDstwwgyYCJopLMqq5IPCRsdgLR2FoeiFVmpZc5CWYKQNn68vef +H6k6FrJz50Naugpja9jVkQQeqLNgp1G6ux8V21fyH7U2J8XyAV03wD8Ku2kugNqDtOf CnaE2KjBYmkGcvD75GYgG2ByTVJiCi14Xk+uI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=C3OGKy4Xs7bfwbjubDC7Rewtx/I9W+4XjVnd2m5nUvo=; b=dXYv8Jfs4U0BQBDKp54QvirDb8y8mV98XaCdn67zIN+eCBkmlQ4uA/FKNYi2uzWMo4 YyA4ycb0YjSoc2gRsNYczQ/f/tX4/edLdbC4HPGKKtN3WepY6y1vfQSLBTVBJ4+723J3 7qiBnyqzOWg7gyNLd4VzLQoBOYAIHs+HwpEk2E9heyrAeY0RD42vdJek39Hgh4mlkoa5 tLyAJvzDroeREEcdk2W44cgPEra0SH1jlZsgR/WiIFl8TDBG3TkbsMjqas1MK1WbFmUw MmD1FvOqDaotE9a47fZ0IT5NSgeY0ZaZ9tuqFHxBI2EUppy0aQqRwOFRPpKPgIcEjgPv brqw== X-Gm-Message-State: AOAM530nzCuamKO/ZpzcilQHGYPP2ywu2EQ1mgQZ/pK3rbhXezDRdS1e fnThBQx/Gb67RuWMeZCBk+lmtDSVV8HZRpnU X-Google-Smtp-Source: ABdhPJxo7yuTP8QrSFokIliVGbVaby1vYTDD0JCleIR6rgNGd7I9CqcY0IPlnTHdS9iga8TL1ywCtA== X-Received: by 2002:a05:651c:1546:: with SMTP id y6mr22650006ljp.394.1635196696568; Mon, 25 Oct 2021 14:18:16 -0700 (PDT) Received: from mail-lj1-f175.google.com (mail-lj1-f175.google.com. [209.85.208.175]) by smtp.gmail.com with ESMTPSA id m15sm1806398ljp.6.2021.10.25.14.18.14 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 25 Oct 2021 14:18:15 -0700 (PDT) Received: by mail-lj1-f175.google.com with SMTP id l5so16060002lja.13 for ; Mon, 25 Oct 2021 14:18:14 -0700 (PDT) X-Received: by 2002:a2e:a4b6:: with SMTP id g22mr22073215ljm.191.1635196694559; Mon, 25 Oct 2021 14:18:14 -0700 (PDT) MIME-Version: 1.0 References: <20211025181634.3889666-1-willy@infradead.org> <202110251225.D01841AE67@keescook> <202110251402.ADFA4D41BF@keescook> In-Reply-To: <202110251402.ADFA4D41BF@keescook> From: Linus Torvalds Date: Mon, 25 Oct 2021 14:17:58 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] secretmem: Prevent secretmem_users from wrapping to zero To: Kees Cook Cc: Matthew Wilcox , Linux Kernel Mailing List , Linux-MM , Jordy Zomer , James Bottomley , Mike Rapoport , Andrew Morton Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 9EDEEB000180 X-Stat-Signature: seraqmxzat7qd4swyd7xg73c5m6cbbzo Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=RBroiKM+; spf=pass (imf25.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.180 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none X-HE-Tag: 1635196692-863971 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 Mon, Oct 25, 2021 at 2:04 PM Kees Cook wrote: > > Is secretmem different? We're trying to count how many of these we have, > this is a common pattern in, for example, the network code which does > this kind of thing a lot. Yes, secretmem is different. A refcount being zero means that the data it referenced no longer exists. That's not what the secretmem counter meant at all. Making it a refcount was simply WRONG. It's not a refcount, it's a usage count, and the fact that syzbot caught the warning just shows how wrong it was. Stop arguing for garbage. It was wrong, just admit it. The semantics for "refcount" is something else than what that code had. As a result, it got reverted. I've applied Willy's patch that actually makes sense. Arguing for garbage in the name of "security" is still garbage. In fact, it only causes confusion, and as such is likely to result in problems - including security problems - later. Because confusion about semantics is bad. And that was what that patch was. And I want to state - again - how dangerous this "refcounts are always prefereable to atomics" mental model is. Refcounts are _not_ fundamentally preferable to atomics. They are slower, bigger, and have completely different semantics. So if something isn't a refcount, it damn well shouldn't use "refcount_t". Linus