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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id A657AC4345F for ; Wed, 24 Apr 2024 23:20:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=78u2uZj4pKdA0NQs4Gd28PYLd6jqamn3CyJjBY54n6k=; b=Hf7yVXvGmyw1rK 2U/iYT5Hz52mgoxw96F+G5pEN+kqQjDbFYzeaYClJOf9D7y6JyKi8vRRgDEhIWAo/RYv5vq48WN/S VGuIwuOrCM9dOoVPD84XsaIPjg6iHXUeRhFsN4BXJG1EN76iZBVr6kFZfaF/Irmy8O8DjYhtbjW9I 8HgCpqKxPiakReTLzS0z6WhAsk2cn3UhjBxhSGPvXeFQo9ytXSWWEZNavOpXmJGsSZscpq+YM9dAe nigtL+MJ2APMaMy09PUwh8UwFX+Diqa3coSmz8UuogTLP2I+D6XENypuBhuoSXz8hglyH57+cpoQw MWdYnfZ6ItYuDhObinZA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rzlub-00000006LuX-2ktp; Wed, 24 Apr 2024 23:20:25 +0000 Received: from mail-pl1-x62c.google.com ([2607:f8b0:4864:20::62c]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rzluY-00000006Ltd-1sI7 for linux-arm-kernel@lists.infradead.org; Wed, 24 Apr 2024 23:20:24 +0000 Received: by mail-pl1-x62c.google.com with SMTP id d9443c01a7336-1e8f68f8e0dso2562505ad.3 for ; Wed, 24 Apr 2024 16:20:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1714000821; x=1714605621; darn=lists.infradead.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=53galFO5b9NlY6rYFvZBx1xxKB41abzyybNlJJlu7mM=; b=FgHVCbZK/W9alu5JvciSIsAa7u3mgv8A8kFIIHz6qaIKfsJbTDypZdNUavIMIriC2M WLb5PDeCPKHr6vQj3yQjQx4MpQe61fdlzi+dApK1Cz4Q1zhfDDSSuDxz1GBRWibUD0ge jX6WLAeiU8SMaPPFpuQaTichKf10uys8jUl5U= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714000821; x=1714605621; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=53galFO5b9NlY6rYFvZBx1xxKB41abzyybNlJJlu7mM=; b=UHalxpaDIBqNUO4nbogSuiMZI0i9iwZ4BVRxOrCxPQmnKC/OC0d4z5reZQOASCf0pA ZfaCqq9Tc1TWwnlYFwDxUHAJV6ZqVGPwsKNC2cD4h7UIRu7Ov+oIZZ1Kl/p1L4uT9OFh i0AaA17iQJThzcV3lvu81Kc5hX3te4A21/+VhDCAF9h7bSqM7lSHbSA/TT8MuI2trOty GWJcpbCfIukoF3vSU8CINws+/cNzjUe2d9Fwea+PSdkSIa6tfr+eEww/kPQEidGv5508 lelvuPVbNAawe7/VIP2IrI/ux5/eNmBsWDojZwuREvyE8bAxOC1r0+httAZ93tmw4uRG 6zaQ== X-Forwarded-Encrypted: i=1; AJvYcCVmob/jU2oa+bHhlPZDA7pGE3qiA1J7mmjBX1gNjtrD87owGEbP3RZOF7GTpVWY7qKAGxpkBwOqE8V18jz7upy8j1qx2VPn70fuaNna0BQ34C7ArzI= X-Gm-Message-State: AOJu0Yw5d9RdGDKhR0gBSaIigdJlSxd56VNcyhCEEOsY6abSiD9nlPUV 1BjXlARQdaySLMqf9MlLvp6PiI3qEals6JNSmaNakTvlRpN6BxADVWk+PQ85jg== X-Google-Smtp-Source: AGHT+IFMkYJNAfNLSmk4oPnPeYVule+RDiUbFbapsmqTHjfPM7QXarEC91Pvng6lRM//0u2jQSClHg== X-Received: by 2002:a17:902:868f:b0:1dd:2eed:52a5 with SMTP id g15-20020a170902868f00b001dd2eed52a5mr3803324plo.37.1714000821414; Wed, 24 Apr 2024 16:20:21 -0700 (PDT) Received: from www.outflux.net ([198.0.35.241]) by smtp.gmail.com with ESMTPSA id c10-20020a170902d48a00b001dd0c5d5227sm12448914plg.193.2024.04.24.16.20.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Apr 2024 16:20:20 -0700 (PDT) Date: Wed, 24 Apr 2024 16:20:20 -0700 From: Kees Cook To: Peter Zijlstra Cc: Mark Rutland , Will Deacon , Boqun Feng , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Jakub Kicinski , Catalin Marinas , Arnd Bergmann , Andrew Morton , "David S. Miller" , David Ahern , Eric Dumazet , Paolo Abeni , "Paul E. McKenney" , Uros Bizjak , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-arch@vger.kernel.org, netdev@vger.kernel.org, linux-hardening@vger.kernel.org Subject: Re: [PATCH 1/4] locking/atomic/x86: Silence intentional wrapping addition Message-ID: <202404241602.276D4ADA@keescook> References: <20240424191225.work.780-kees@kernel.org> <20240424191740.3088894-1-keescook@chromium.org> <20240424224141.GX40213@noisy.programming.kicks-ass.net> <202404241542.6AFC3042C1@keescook> <20240424225436.GY40213@noisy.programming.kicks-ass.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20240424225436.GY40213@noisy.programming.kicks-ass.net> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240424_162022_559813_16F7E7DA X-CRM114-Status: GOOD ( 28.18 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Apr 25, 2024 at 12:54:36AM +0200, Peter Zijlstra wrote: > On Wed, Apr 24, 2024 at 03:45:07PM -0700, Kees Cook wrote: > > On Thu, Apr 25, 2024 at 12:41:41AM +0200, Peter Zijlstra wrote: > > > On Wed, Apr 24, 2024 at 12:17:34PM -0700, Kees Cook wrote: > > > > > > > @@ -82,7 +83,7 @@ static __always_inline bool arch_atomic_add_negative(int i, atomic_t *v) > > > > > > > > static __always_inline int arch_atomic_add_return(int i, atomic_t *v) > > > > { > > > > - return i + xadd(&v->counter, i); > > > > + return wrapping_add(int, i, xadd(&v->counter, i)); > > > > } > > > > #define arch_atomic_add_return arch_atomic_add_return > > > > > > this is going to get old *real* quick :-/ > > > > > > This must be the ugliest possible way to annotate all this, and then > > > litter the kernel with all this... urgh. > > > > I'm expecting to have explicit wrapping type annotations soon[1], but for > > the atomics, it's kind of a wash on how intrusive the annotations get. I > > had originally wanted to mark the function (as I did in other cases) > > rather than using the helper, but Mark preferred it this way. I'm happy > > to do whatever! :) > > > > -Kees > > > > [1] https://github.com/llvm/llvm-project/pull/86618 > > This is arse-about-face. Signed stuff wraps per -fno-strict-overflow. > We've been writing code for years under that assumption. Right, which is why this is going to take time to roll out. :) What we were really doing with -fno-strict-overflow was getting rid of undefined behavior. That was really really horrible; we don't need the compiler hallucinating. > You want to mark the non-wrapping case. What we want is lack of ambiguity. Having done these kinds of things in the kernel for a while now, I have strong evidence that we get much better results with the "fail safe" approach, but start by making it non-fatal. That way we get full coverage, but we don't melt the world for anyone that doesn't want it, and we can shake things out over a few years. For example, it has worked well for CONFIG_FORTIFY, CONFIG_UBSAN_BOUNDS, KCFI, etc. The riskier condition is having something wrap when it wasn't expected (e.g. allocations, pointer offsets, etc), so we start by defining our regular types as non-wrapping, and annotate the wrapping types (or specific calculations or functions). For signed types in particular, wrapping is overwhelmingly the uncommon case, so from a purely "how much annotations is needed" perspective, marking wrapping is also easiest. Yes, there are cases of expected wrapping, but we'll track them all down and get them marked unambiguously. One thing on the short list is atomics, so here we are. :) -Kees -- Kees Cook _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel