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 C5EDDC433EF for ; Mon, 25 Oct 2021 23:37:23 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 554FC60E73 for ; Mon, 25 Oct 2021 23:37:23 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 554FC60E73 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 DFA9194000B; Mon, 25 Oct 2021 19:37:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D82EE940007; Mon, 25 Oct 2021 19:37:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C24E994000B; Mon, 25 Oct 2021 19:37:22 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0186.hostedemail.com [216.40.44.186]) by kanga.kvack.org (Postfix) with ESMTP id ACB4B940007 for ; Mon, 25 Oct 2021 19:37:22 -0400 (EDT) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 64F508249980 for ; Mon, 25 Oct 2021 23:37:22 +0000 (UTC) X-FDA: 78736573524.18.DCEF7CD Received: from mail-lj1-f169.google.com (mail-lj1-f169.google.com [209.85.208.169]) by imf18.hostedemail.com (Postfix) with ESMTP id 0840F4002088 for ; Mon, 25 Oct 2021 23:37:21 +0000 (UTC) Received: by mail-lj1-f169.google.com with SMTP id d13so11464005ljg.0 for ; Mon, 25 Oct 2021 16:37:21 -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=G9jEnj3xyHv4ymCBAOlICtoiP3KvPiyAqU8Gic5xaL0=; b=h6oyWndBCuvT0dDkXPKAeLffQ50rysGpHNLz6ER8UKsSnXUuy0FS/9DEHHTw6R+sEj T57FkLvDjPoMNyRxu3/Hi2TLe0RxtYJ0J1jRmL50PMUD7w3pBaJ/LJwaxWex+SGT/pcR V8bBZ7QNvS6SSKsfTZ/2L59xwpCwOsHmBySu4= 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=G9jEnj3xyHv4ymCBAOlICtoiP3KvPiyAqU8Gic5xaL0=; b=r4y6ZFEcTufSg0+3E60CNWZhHvZ3VA+Wg4QgASQRYGrlzebhvJN5Qy7GKRpfC6d6Te 3WatqXBMoPCxswXi4F9ofpZ3n5R0eUQm7EBcaFw9n5svTNR9tUwv3KFk2euErfQW1uY6 crNZjj/g27yo6tHJj3pJWrBlx4uIVu5Y2Ze065PNOw/Dlba9phHVFoIUTDndzQU4B/6m f5XHi0Vgf2eIt82TgNMun4iaUP7//Ptx1i/nG3JS8nOQ2RnTev9yUf1q6H2IPwXYoh2j wP/0H2lUYQb6L3gFfaEC6KVJNPqtdDwOoRrWcMfv6OJItByNpVBrbIrjXeurRYpbY3I3 ztgg== X-Gm-Message-State: AOAM5303/67GjHXAf6M4YZrCb9oQD5Z5bol8/MVslMhxR1btTj7hSa33 h891D5wh1vmj7gaQCsPV9FiN24d0F5Y8H3K3 X-Google-Smtp-Source: ABdhPJylhNhMfTVvYmqWfewIBtC2samt6pq7JTnU1cIIz/mWSIozOGXYT6Tu/CW3znegTiIy1OniUw== X-Received: by 2002:a05:651c:1506:: with SMTP id e6mr14210320ljf.193.1635205039063; Mon, 25 Oct 2021 16:37:19 -0700 (PDT) Received: from mail-lj1-f173.google.com (mail-lj1-f173.google.com. [209.85.208.173]) by smtp.gmail.com with ESMTPSA id m13sm151843lji.132.2021.10.25.16.37.17 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 25 Oct 2021 16:37:18 -0700 (PDT) Received: by mail-lj1-f173.google.com with SMTP id d13so11463868ljg.0 for ; Mon, 25 Oct 2021 16:37:17 -0700 (PDT) X-Received: by 2002:a2e:a407:: with SMTP id p7mr22948041ljn.68.1635205037628; Mon, 25 Oct 2021 16:37:17 -0700 (PDT) MIME-Version: 1.0 References: <20211025181634.3889666-1-willy@infradead.org> <202110251225.D01841AE67@keescook> <202110251402.ADFA4D41BF@keescook> <202110251438.1762406A5@keescook> In-Reply-To: <202110251438.1762406A5@keescook> From: Linus Torvalds Date: Mon, 25 Oct 2021 16:37:01 -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-Stat-Signature: b864afi4yzfocc6n4nw46wqsig9wwasw Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=h6oyWndB; spf=pass (imf18.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.169 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 0840F4002088 X-HE-Tag: 1635205041-263890 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 3:30 PM Kees Cook wrote: > > > A refcount being zero means that the data it referenced no longer exists. > > I don't disagree with this definition, but I would like to understand how > some other use-cases fit into this. I certainly hope that there are no other use-cases for 'recount_t', because that "zero is invalid" is very much part of the semantics. If we want other semantics, it should be a new type. > What about the case of what > I see that is more like a "shared resource usage count" where the shared > resource doesn't necessarily disappear when we reach "no users"? So I think that's really "atomic_t". And instead of saturating, people should always check such shared resources for limits. > i.e. there is some resource, and it starts its life with no one using it > (count = 1). You are already going off into the weeds. That's not a natural thing to do. It's already confusing. Really. Read that sentence yourself, and read it like an outsider. "No one is using it, so count == 1" is a nonsensican statement on the face of it. You are thinking of a refcount_t trick, not some sane semantics. Yes, we have played off-by-one games in the kernel before. We've done it for various subtle reasons. For example, traditionally, on x86, with atomic counting there are three special situations: negative, 0 and positive. So if you use the traditional x86 counting atomics (just add/sub/inc/dec, no xadd) then there are situations where you can get more information about the result in %eflags if you don't use zero as the initial value, but -1. Because then you can do "inc", and if ZF is set, you know you were the _first_ person to increment it. And when you use "dec", and SF is set afterwards, you know you are the _last_ person to decrement it. That was useful when things like "xadd" weren't available, and cmpxchg loops are expensive. So we used to have counters where -1 was that "zero point". Very similar to your "1 is the zero point". But was it _logical_? No. It was an implementation trick. I think we've removed all those cases because it was so subtle and confusing (but maybe we still have it somewhere - I did not check). So we've certainly played those kinds of games. But it had better be for a really good reason. > I don't see as clear a distinction between secretmem and the above > examples. I really don't see what's wrong with 'atomic_t', and just checking for limits. Saturating counters are EVIL AND BAD. They are a DoS waiting to happen. Once you saturate, the machine is basically dead. You may have "protected" against some attack, but you did so by killing the machine and making the resource accounting no longer work. So if a user can ever trigger a saturating counter, that's a big big problem in itself. In contrast, an 'atomic_t' with a simple limit? It just works. And it doesn't need illogical tricks to work. Stop thinking that refcount_t is a good type. Start realizing the downsides. Start understanding that saturation is a HORRENDOUSLY BAD solution, and horrible QoI. Linus