Received: by 2002:a05:7412:31a9:b0:e2:908c:2ebd with SMTP id et41csp4392493rdb; Fri, 15 Sep 2023 00:06:26 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGdfsmVLXlnxq3rDzd8Dq+s8XiapB8sFNt7iEeP0muGYzNriCxC2Uvs/EnuRlw3MtItufXK X-Received: by 2002:a17:902:d485:b0:1c3:9764:764f with SMTP id c5-20020a170902d48500b001c39764764fmr856462plg.48.1694761586620; Fri, 15 Sep 2023 00:06:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1694761586; cv=none; d=google.com; s=arc-20160816; b=UTjd12NjUgppklEg4xfRhZBrAFQOyMTLVLSrJ2n6wIv6ebywfJNy8/I/FQS2hTaEJp aZByXfvPqH+x6LPb/QjLSbDumdo9yD2nCwC/Xjn4yK+iR+gO4K3Z2Ly5svJLJgQjQ8Ma P4s70HpuwKgnz4FLpjLb0PXI5VGsAgCCsRtmaClb/ZVBhGItXCPwqKX2Bdes5PRyhRtk SvjBXv4cc8VZXXWD5ek16kWBiTm6+WjM5at6Hz4BugeGxJwLr1CPFcAx/MUvTgy7MgRC niYM3C4VE3tQ2LGhYo/ogtYies6nQDEv498/KdEUqMLmBHjOiyczP+2Ky0v8JVUjcTky /zGw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=ccX2gvw1qSPWr5qXb0fG86wgmS6e9ZRJiYSlfkRPwO8=; fh=W5nOqqsncVu3KirO+6jJSiSDc3CrEcJPyxelHlBkDQ0=; b=xAaYlU9Jpg6lid50MADdWuVbxk6NvczUWdTcvi7y7/H9O05NKsLeQ1j8B4rpFAnx/v 5RMSLmAUxMxreH3sFtMHw0/2NwvIM2BflDLTuK/EqaEUBX9HdX5Vby44OmvXedChZmmO DqJ5maW1/EJWOLZrW3cnCdzl95qVu3KrdYbBdoY3kd6ZjeCk6tY6uFUCD3aePtTZ+sGE x1SMfAyi+EulHoGJe5eKC6DYrYN9YWv5p32Wh1XbuPsG6hh37xr/v5roWesXTRZKNa9N yZp7nWzqAhOSKTavuxjDKnEszto7bBZ46cRq4iGq4PC3vGbwz2MYL99/Y7+GfihAg+wt sPqw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=Uvn8PwkR; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from lipwig.vger.email (lipwig.vger.email. [2620:137:e000::3:3]) by mx.google.com with ESMTPS id km8-20020a17090327c800b001b886a0c366si2818695plb.122.2023.09.15.00.06.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 15 Sep 2023 00:06:26 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) client-ip=2620:137:e000::3:3; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=Uvn8PwkR; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by lipwig.vger.email (Postfix) with ESMTP id 3BB9882A3D38; Thu, 14 Sep 2023 17:20:52 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at lipwig.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229499AbjIOAUs (ORCPT + 99 others); Thu, 14 Sep 2023 20:20:48 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52160 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230213AbjIOAUr (ORCPT ); Thu, 14 Sep 2023 20:20:47 -0400 Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9C9972695 for ; Thu, 14 Sep 2023 17:20:43 -0700 (PDT) Received: by mail-pl1-x62b.google.com with SMTP id d9443c01a7336-1c0db66af1bso12190725ad.2 for ; Thu, 14 Sep 2023 17:20:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1694737243; x=1695342043; darn=vger.kernel.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=ccX2gvw1qSPWr5qXb0fG86wgmS6e9ZRJiYSlfkRPwO8=; b=Uvn8PwkRMklZOZnQ9lTTyCA74BdG/Yst6jcEdbA9N3J4GhQFO/YcwGRgijdk8SpV9w 7PnIWQNzacbp9dOmZDHrradgNEi7QUhJevAARvIqhz9LebPrqcRPUFdBLQuUNkrFEN44 UuMFelcpfpPgNvQfwlQzrzKOrq3G25U2x+atc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694737243; x=1695342043; 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=ccX2gvw1qSPWr5qXb0fG86wgmS6e9ZRJiYSlfkRPwO8=; b=wQI//clBnb1j1pAtxD58A10xyFVcb99GM4/fLfDg0qc9u0pslWsBPF5FltPq7H1bkM D0Q/LYSqt2u4w4D7yS5F47QGQrTESCTlHuRLwpGXLYRIoyrcejj1UOHjHlR3GG7oFBak r0fPsMMVOSfWckZGhqki96TT3GS11r5nieJjHhGSfjP3mdFbvFfy+ylVdl62yp33sxCq nYf0kd2bTUoK0TV28RI460bG2ViZrMa14tFgW/mAFOY/PJpjn/jEqFmY4oSTfOTOOYqS ZwXR7Cn0IR1ODrrkxIf0yUEO9kJ8gupZQsfnkjtrhz3p9fAiS0Q5GgKxLcvB81AT/MPC ENqQ== X-Gm-Message-State: AOJu0YxFs27BzQ3h5CcV8r7zED4UmtVoSvr6mzr3qMnzDipK+pXvSZ6u BNpUFzW5htrbWHV7DvUZc534aQ== X-Received: by 2002:a17:902:dac1:b0:1bb:c64f:9a5e with SMTP id q1-20020a170902dac100b001bbc64f9a5emr224115plx.5.1694737243036; Thu, 14 Sep 2023 17:20:43 -0700 (PDT) Received: from www.outflux.net (198-0-35-241-static.hfc.comcastbusiness.net. [198.0.35.241]) by smtp.gmail.com with ESMTPSA id h18-20020a170902eed200b001b8b45b177esm555049plb.274.2023.09.14.17.20.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 14 Sep 2023 17:20:42 -0700 (PDT) Date: Thu, 14 Sep 2023 17:20:41 -0700 From: Kees Cook To: Kent Overstreet Cc: Stephen Rothwell , Linux Next Mailing List , Linux Kernel Mailing List , linux-hardening@vger.kernel.org Subject: Re: linux-next: Tree for Sep 12 (bcachefs) Message-ID: <202309141708.C8B61D4D@keescook> References: <20230912152645.0868a96a@canb.auug.org.au> <202309131803.6A3C1D05A@keescook> <20230914193807.ozcmylp6n6dsqkbi@moria.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230914193807.ozcmylp6n6dsqkbi@moria.home.lan> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (lipwig.vger.email [0.0.0.0]); Thu, 14 Sep 2023 17:20:52 -0700 (PDT) X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lipwig.vger.email On Thu, Sep 14, 2023 at 03:38:07PM -0400, Kent Overstreet wrote: > On Wed, Sep 13, 2023 at 06:17:00PM -0700, Kees Cook wrote: > > It looks like you just want a type union for the flexible array. > > This can be done like this: > > > > struct bch_sb_field_journal_seq_blacklist { > > struct bch_sb_field field; > > > > union { > > DECLARE_FLEX_ARRAY(struct journal_seq_blacklist_entry, start); > > DECLARE_FLEX_ARRAY(__u64, _data); > > }; > > }; > > Eesh, why though? > > Honestly, I'm not a fan of the change to get rid of zero size arrays, > this seems to be adding a whole lot of macro layering and indirection > for nothing. The C standard doesn't help us in that regard, that's true. But we've been working to get it fixed. For example, there's discussion happening next week at GNU Cauldron about flexible arrays in unions. It's already possible, so better to just fix the standard -- real world code needs it and uses it, as the bcachefs code illustrates. :) > The only thing a zero size array could possibly be is a flexible array > member or a marker, why couldn't we have just kept treating zero size > arrays like flexible array members? Because they're ambiguous and then the compiler can't do appropriate bounds checking, compile-time diagnostics, etc. Maybe it's actually zero sized, maybe it's not. Nothing stops them from being in the middle of the structure so if someone accidentally tries to put members after it (which has happened before), we end up with bizarre corruptions, etc, etc. Flexible arrays are unambiguous, and that's why we committed to converting all the fake flex arrays. The compiler does not have to guess (or as has been the case: give up on) figuring out what was intended. Regardless, I'm just trying to help make sure folks that run with CONFIG_UBSAN_BOUNDS=y (as done in Android, Ubuntu, etc) will be able to use bcachefs without runtime warnings, etc. Indexing through a 0-sized array is going to trip the diagnostic either at runtime or when building with -Warray-bounds. -Kees -- Kees Cook