From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) by sourceware.org (Postfix) with ESMTPS id 7D6773858D1E for ; Thu, 11 May 2023 19:07:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7D6773858D1E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=chromium.org Received: by mail-pf1-x434.google.com with SMTP id d2e1a72fcca58-64a9335a8e7so339277b3a.0 for ; Thu, 11 May 2023 12:07:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1683832061; x=1686424061; 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=BQWcZP56mRpv21XSp3mAh6/oFkWbzx9zBnR5fexEFcE=; b=CMSgfMDqTVnZr9kbo0RfFWiLTyc/ZAK5aKFsvdUaOrxg1ETzlJlgcyTibi60ZRNN0a /rOB9iTY7Ee9ik1/8GaSgqc1DSvS3wJnc+2uoNypk6Tf/ZPXYldIr4WJIcyD/BiiN3vR DiVHtfB5vylMMmqSvZm+ePPqn3ubHmwvpCgCg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683832061; x=1686424061; 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=BQWcZP56mRpv21XSp3mAh6/oFkWbzx9zBnR5fexEFcE=; b=WiV1EPrRK53ZkitmR+TvgYOUv+gFm7y2DKNNLXIvjoounYflvnmSnMx00h9wxXn1ZQ KNrt34zdKzC/gBd2/C0phcNCcAkRypb0D8uDX69NZ3XrU39SWeAgETfi51z/bH/tFr/B DLDWsDABvJE3VMbeRgOYBg1iHaEHVCAPiqm5X2/7PNZYxHMWCDfZgNbzljbE8KrqGDj9 GkKKlrzQ4ru8+YeimyQb/cqx3SFjXudzNq9KqgptW8SluaIJjgJGmxBTBM8GDRD7Sl4i whJ8XTvLVsXjNe+Fn+sz/Uvm3f9DJ1Wh6Ba1kUk0D/ENKjKXDcS4mO//0tHhvheSbEOE RWbQ== X-Gm-Message-State: AC+VfDxOgMvETmPy9dWcrqdnecvTfJwSDkCb+Du7FnU7EJKv5LtNeJA4 nylWTkS88QhKzxyo5RlzTRNf7g== X-Google-Smtp-Source: ACHHUZ4w/bmg/Fb6BPdd9vBe7MRp7/HQR8TzAlPAcT7ognmeiYRxRnTu9kFmUbZcNUVWcG3DvurkDA== X-Received: by 2002:a17:90a:bb05:b0:250:af6d:bd7b with SMTP id u5-20020a17090abb0500b00250af6dbd7bmr10810154pjr.24.1683832061246; Thu, 11 May 2023 12:07:41 -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 cl2-20020a17090af68200b002465a7fc0cfsm15756738pjb.44.2023.05.11.12.07.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 11 May 2023 12:07:40 -0700 (PDT) Date: Thu, 11 May 2023 12:07:40 -0700 From: Kees Cook To: Alejandro Colomar Cc: GCC , Alejandro Colomar , Andrew Clayton , Andrew Clayton , linux-hardening@vger.kernel.org Subject: Re: [wish] Flexible array members in unions Message-ID: <202305111158.C78642624@keescook> References: <44940599-7b43-99f6-5b09-4f050d645c7b@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44940599-7b43-99f6-5b09-4f050d645c7b@gmail.com> X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,JMQ_SPF_NEUTRAL,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Thu, May 11, 2023 at 06:29:10PM +0200, Alejandro Colomar wrote: > On 5/11/23 18:07, Alejandro Colomar wrote: > [...] > > Would you allow flexible array members in unions? Is there any > > strong reason to disallow them? Yes please!! And alone in a struct, too. AFAICT, there is no mechanical/architectural reason to disallow them (especially since they _can_ be constructed with some fancy tricks, and they behave as expected.) My understanding is that it's disallowed due to an overly strict reading of the very terse language that created flexible arrays in C99. > [...] > Currently, the Linux kernel has to go through some hoops due to this > restriction: > > > $ grepc -tm __DECLARE_FLEX_ARRAY * > include/uapi/linux/stddef.h:42: > #define __DECLARE_FLEX_ARRAY(TYPE, NAME) \ > struct { \ > struct { } __empty_ ## NAME; \ > TYPE NAME[]; \ > } Yes, we've had to do this as we eradicate all the fake flexible arrays in the kernel which cause endless bugs[1]. Additionally, we'll be using -fstrict-flex-arrays=3 soon to let existing array bounds checking mitigations gain coverage over trailing arrays. All of this means that we're converting a lot of code that is happily using dynamically sized arrays in unions, etc. [1] https://people.kernel.org/kees/bounded-flexible-arrays-in-c -- Kees Cook