From nobody Wed Jul 5 19:08:14 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 4Qx8ML2MkWz4mFS7 for ; Wed, 5 Jul 2023 19:08:30 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-20.consmr.mail.gq1.yahoo.com (sonic313-20.consmr.mail.gq1.yahoo.com [98.137.65.83]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 4Qx8MK5zGZz3JHM for ; Wed, 5 Jul 2023 19:08:29 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1688584107; bh=0lSY2S76CgpXMx2or7hA/xmJkn50ZrVkxURYRgmK7b4=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=JCejfWdZ92KyMZZ2UrjBKdHLr0mmVm7BLg9SGpSC93QnB1CA+1566gIPD6VJONWlsAtyqavh6PtY021gK2hAZbE0hZECJDN7xFx3cvflf4f2/qvsnT3pPtp7KkDH1w9D6PJN+QqPq5BFqwswrGxJYRkaCgtRr0zWxhF8bBFqNXXJJCKmcaC2UIsLK7bVXqT1hi1/NHqd4AvsY5gxMLBo953wh3LdmfFvt30gEM+I0VxJfCljdgOZVzhzEZ3Y4myMK+pCmOH4RhdQVTAaQTysQWdc3tHkFayXCaII48PmMSdefa419Z7RRFZoJSfMr5dhzv3oyz2hAULDzOtIOzb5VQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1688584107; bh=4738Zf6pkD0zreb4ttEoX6Iya7YT6zdjOhCqrTnTSA1=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=ZwPaoJ6DTvNbozGflDaqVwVFNfn+z3MYReBH4Eb/av6gNhX4TddJwGRo5UJQ6ioqc1yySYOBcKZSTSxzLU6borX2KVjOn66ccVG5dAsyikQPiCGphFXA9gzyg2XjsaSK3flguOuGzNUSEEHKzgkBwXhHYakASDGN4YQvntBQlEsSHBBrMyKg1wTekAGjrg9Jfac9I8zhu5X6aVYsHcOeDfQdQRlX9odmAztG9B0YeX76K7uDZXFtBu5h2ZFjY3UvFkNEp7pVXju9GBH3uMQlEXu3ScfTHDGDtyLyFIto7IdgQHC0Cr2ky6SUMDLNpJPnc2LJDKYUrFmWin6Sc+gwhA== X-YMail-OSG: GhWTQz4VM1nrSEIsRczh4QGqjV0s3Ju1f5.lHvVK6zxnIlSqsi6mQ.sa1gzy1u5 LGLWZ4335.kdfN.8Zp1gIqpP67sG.zWvDFDSnbktOLc2XeCFEct12wOI4pNIyYAa9F7pZwkDBw_i H02JHJbMj.eSXcNaceqUBjqWB0rmSfj4aEOYuni.kz9It1i7lQSKbjgJvtEO1kx_dhR1aCvqikhC buTIGK8vwJdDKpDGSsY.RPnZO4jcHQ.gimpdLM8cDXfGM1avrAa2TBpACxl_0x3DVPzuqZMPSAI5 BgI2mCgjIrxfmFMvCPdK.TLP0019.G5PYceV6uk.05kZnLsImqAXBmUPqGAdBD.D.93Pr3Adm71g jOhPiCEz4Dyj44gAcbLhGpX55RQ9YAmaJca9ce3vOvFHzHuD7kyDqFXJJ8nYrYD2cU4GCT.dAi8t FO.wossXePHRDkyGsRWvujqoEGHp_6IN7MNxnnu3tpgBYZpN742wKfl8uzMFkCxGaZ6nLb5et9iK x4Ugh9NbjdBRZoch.uJEe4CxX7gRfETPGQTck8Oudu.S4lgvjDUbDijiSDph4Q0BVmny4OkrPxsf obddWbq0zbkGMdzYDKUnjtoB.87SxIEeIR3EeFXYaGU1vx37T5RBMfqssUhC0lTTn51oMUVv82YY VLqmovD28JqX23qAt46JecYr_x8bEA6vaQ6godobKEyJ7u7dJUXyaTyeOhb0QvfPQQlwYtn6Q0Eb QuTNh6gZQz2MZknBpOwbqKO6_fGmxesAZ1_QBdnbklyT.JdVS.3GF9sbJXIxhFe7b4aLNScHLyiD f5FPpaihSpCJLjAHEDmjtgA_ZhUc6hyTUA26r_6esj9nyUww3d8ZRxGhyarCiGJK_wjzab5VVpeo tYH7Eonm_LeZEHA7XSLtPVmU2MMcHmgJeJDMiLvjYWvxt8lmxaBPq1eWnosHTXSFNo0XdWG1nEKy 7OtFkYFt5MeaAKYST0g8x66qVnhL_QnwQBeheZMG1rsb8Hj4zCIvZU0TEThLo6utl1rJ1XeW3G0P MHt2A74Y4hZK.bSPzQd.WxbV8c1c7ty.SJZo4CyTh0Mrz61ELmtTiIc_cjOcEJF1baTpFT1lEw5J UEP.kYVbRDHodS90xM2Hyz7cnXFQSicTJrFNu4jFAVRSFHkQkuEuG2a5uvIAoJStfZY5Vyo3.yKv z4odWgXJZXE79EEPTxmi8NsZuPdc44fhHU2N.BmaCvPR8.U3o66Lehg2wKtcIPkrQ66GacZcC2J1 WUTkRzX_ByYfvXJe6Je0RZUPNiz._Xb4b3.2PIOBJ2m5NrdPnUKB_7iRfIK.EUaOeDkLGqzryIF3 5lBrtpT6etUE9s2BjmyzByzMF.TbITjMzsak79mYG4rGr0uzZWwRdBH.kmKwoWVJz8jSDQNZMzlM lUbVguW_F2aKwbXN9K2Og_eTIW5aEtMtdeiFbYhfo0RK472W5fJfS5opj7hmRSNTcvg2Sf2JOZxG xRfXIxUnflLF2O3X4T0nEnwDDMiI3TqBR.7iB15bVsn3XRknQ5QykFjCC9jRNq.HkdwWv12JGgZc nt842JwLWZMoANx3CxjFPGitu.AcdJNYQNbXR1FmaBDHykD7oLj7vm1Yk.R3mgfeg.m1kEAnTWuO BfakZbCqrtpwoSykYmAR02N7WsGl_4wc8.caCmYkD87.lLWmDyucUxiEKpqHswGY22cKVdtdPa8w 6mxNJhyUrz8OWQ4j_9VxozNm9EKqCddDg1_yI7vxS9O0VReUcesmWhBRJSkAJkbFdRcICf.QqeSg rSeyeNcMD6IR0tAPz8P2va2sS7oMaAKxPYV_vYYmm2ow.N97WXviO50tVRSHkFIm73wQgSxXjj5A 2luigPgO.FcqnFKUJm3SUPbH2D0H1oZBHyZwzB9dNreI72TB_jr95Z3nB_g2zKMYRBQxIOwbzhT8 qSV7Fqz4aYYI.AbSuQmrBWIQKN0VzWOyr5mVJZofP_HT6QkziYIqtiUIGfLRgHxzkRVYM9uPSNq7 knpFKAkIYgr39eHU5Tf2Pp_lM_AQHDoSGZYYhDdMD70hpV8uL2FMYHoDQt7_F3qQxBDIh9As2XS4 .y9VeyxUd11TiqUKEg42GItmwSQaP1kJzpv7ieuP4xDvm42IBQvz_8Z4ewPIT7Il_GzvjCZRCKAo G_PzSZGanjR4BsNd1ms3E5qp.eLiclpZhgbePjHx_JTNnoY5pSESxS583rR3ljnQuRTiJpKPkai6 xn1znC9UlWr6zRAslbJf55mBKIGVz2W0xu3f4o1CO2YthnuryMKj0pCcuMw73EhV6mEWBNhrhApy pUg-- X-Sonic-MF: X-Sonic-ID: 76d4f8f7-5938-466d-8e77-e1b7ed503515 Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Wed, 5 Jul 2023 19:08:27 +0000 Received: by hermes--production-ne1-6d679867d5-nhrqn (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 92d3218596b48b9556c77a25ff8ef47b; Wed, 05 Jul 2023 19:08:25 +0000 (UTC) Content-Type: text/plain; charset=us-ascii 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 (Mac OS X Mail 16.0 \(3731.600.7\)) Subject: Re: git: 005aa1743b42 - main - modules: bzero the modspecific_t From: Mark Millard In-Reply-To: Date: Wed, 5 Jul 2023 12:08:14 -0700 Cc: dev-commits-src-main@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <4EC1C526-0155-4E46-974B-1B8421D21AAD@yahoo.com> References: To: Brooks Davis X-Mailer: Apple Mail (2.3731.600.7) X-Rspamd-Queue-Id: 4Qx8MK5zGZz3JHM X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Jul 5, 2023, at 11:10, Brooks Davis wrote: > 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=3D005aa1743b42b52fbd49b9d5ec448169= 02b6ee9f >>>>>=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 = initialized >>> 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. >=20 > 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. Yep: nicer notation. > 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. I think the worry goes the other way: the historical stack content exposed in some of bytes in the union might prove to be sometimes "interesting", even if partial. The change avoids that possibility. =3D=3D=3D Mark Millard marklmi at yahoo.com