From nobody Wed Jul 5 18:10:45 2023 X-Original-To: dev-commits-src-main@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Qx74s2DrTz4m1KQ for ; Wed, 5 Jul 2023 18:10:53 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Qx74r3RfZz4dHZ for ; Wed, 5 Jul 2023 18:10:52 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of brooks@spindle.one-eyed-alien.net has no SPF policy when checking 199.48.129.229) smtp.mailfrom=brooks@spindle.one-eyed-alien.net; dmarc=none Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id A21AD3C0199; Wed, 5 Jul 2023 18:10:45 +0000 (UTC) Date: Wed, 5 Jul 2023 18:10:45 +0000 From: Brooks Davis To: Mark Millard Cc: dev-commits-src-main@freebsd.org Subject: Re: git: 005aa1743b42 - main - modules: bzero the modspecific_t Message-ID: References: List-Id: Commit messages for the main branch of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-main@freebsd.org X-BeenThere: dev-commits-src-main@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: X-Spamd-Result: default: False [-1.80 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FORGED_SENDER(0.30)[brooks@freebsd.org,brooks@spindle.one-eyed-alien.net]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_TO(0.00)[yahoo.com]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; R_SPF_NA(0.00)[no SPF record]; ASN(0.00)[asn:36236, ipnet:199.48.128.0/22, country:US]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[dev-commits-src-main@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_NEQ_ENVFROM(0.00)[brooks@freebsd.org,brooks@spindle.one-eyed-alien.net]; FREEFALL_USER(0.00)[brooks]; ARC_NA(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[freebsd.org]; TO_DN_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4Qx74r3RfZz4dHZ X-Spamd-Bar: - X-ThisMailContainsUnwantedMimeParts: N On Mon, Jul 03, 2023 at 04:20:41PM -0700, Mark Millard wrote: > On Jul 3, 2023, at 15:27, Mark Millard wrote: >=20 > > Brooks Davis wrote on > > Date: Mon, 03 Jul 2023 21:24:11 UTC : > >=20 > >> On Sat, Jul 01, 2023 at 10:59:22PM +0000, Ka Ho Ng wrote: > >>> The branch main has been updated by khng: > >>>=20 > >>> URL: https://cgit.FreeBSD.org/src/commit/?id=3D005aa1743b42b52fbd49b9= d5ec44816902b6ee9f > >>>=20 > >>> commit 005aa1743b42b52fbd49b9d5ec44816902b6ee9f > >>> Author: Ka Ho Ng > >>> AuthorDate: 2023-07-01 19:41:53 +0000 > >>> Commit: Ka Ho Ng > >>> CommitDate: 2023-07-01 22:58:46 +0000 > >>>=20 > >>> modules: bzero the modspecific_t > >>>=20 > >>> Per https://reviews.llvm.org/D68115, only the first field is > >>> zero-initialized, meanwhile other fields are undef. > >>>=20 > >>> The pattern can be observed on clang as well, that when > >>> -ftrivial-auto-var-init=3Dpattern is specified 0xaa is filled for > >>> non-active fields, otherwise they are zero-initialized. > >>> Technically both are acceptable when using clang. However it > >>> would be good to simply bzero the modspecific_t in such case to > >>> be strict to the standard. > >>=20 > >> IMO this is a move in the wrong direction. We should see about > >> switching this file to C17 which IIRC removes this bug in the standard. > >>=20 > >> Ideally we'd be moving to C23 where we can just do foo =3D {} > >> to zero things, but we've got a ways to go... > >=20 > > Can you point me to where some (draft?) C?? standard material indicates > > that: > >=20 > > A) pad bytes are to be determined to have a specific value? > >=20 > > B) union bytes unused by a smaller size field that is the one initializ= ed > > are to be determined to have a specific value? > >=20 > > My copy of N2176 for ISO/IEC 9899:2017 still has the J.1 Unspecified > > behavior wording: > >=20 > > -- The value of padding bytes when storing values in structures > > or unions (6.2.6.1) > >=20 > > -- The values of bytes that correspond to union members other > > than the one last stored into (6.2.6.1) > >=20 > > As long as those are true, initializer notation is not guaranteed > > to avoid memory content leakage for the padding bytes and unused > > bytes for smaller union fields. > >=20 > > (I'll not generate wording to deal with trap representations for such > > issues, something C++ avoids.) > >=20 >=20 > I just got a copy of N3096 for ISO/IEC 9899:2023 and it still > reports for memcmp (note 379): >=20 > QUOTE > The unused bytes used as padding for purposes of alignment within > struture objects take on unspecified values when a value is stored > in the object (see 6.2.6.1). Strings shorter than their allocated > space and unions can also cause problems in comparison. > END QUOTE >=20 > The J.1 Unspecfied behavior items are still there as well. [These > are numbered in the C23 draft: (10) and (11).] >=20 > Such suggests no "fix" is present in that C23 draft. I was wrong about padding being corrected :(, however, C23's empty initializizer (struct foo =3D {};) does guarantee zeroing and we should be moving to it as soon as the short list of compilers we care about it support it. For the original commit, I think it's entirely harmless to leak the pad with 0xaa's. The details of which fields are explicitly initialized is not a secret. -- Brooks