From nobody Mon Jul 3 07:11:03 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 4QvcXs3xgHz4lHS2 for ; Mon, 3 Jul 2023 07:11:25 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-54.consmr.mail.gq1.yahoo.com (sonic307-54.consmr.mail.gq1.yahoo.com [98.137.64.30]) (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 4QvcXq5RLqz3knJ for ; Mon, 3 Jul 2023 07:11:23 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=oJVnVCv1; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.30 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1688368281; bh=pzKxF54bdrXNr5i880SMnLxB9+n2r0TNX4HOPiSQ26w=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=oJVnVCv1HtwH9lZD5VOkqA2VStDsnc8lQRuDDAFCdB6PyRG4XCA/ItYa5ovQgcea4SP+e6OYdvYXbfc0dcpuaTuSlxukXlocNMnn6sXC6CpVHy667SWLsKWfF3WyjHVYvT7Xexz8CoY3vRb77eMzDiJcTBkRzs1eat41uDsGrBzLmNFVPvqKrfMjG81MS4xXkNajAcdItpYKsTGUbTJ9GqbMKJw2gnMET6KHgz+eBOzTuwJnxYho37c1rVY2Ssyd4eFayMSnD3Xmsll5SjQByL85Myks/4czMWGOZmHQRDUboaqu1J0M7UZomEl31u5ggq+rNwCUbo0BiyNz6F7TOw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1688368281; bh=dbUE9cPWqNRUoKeIaOqgpkVkiROg7EKtwGj3xvl+Kuy=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=sfX8J0dMODKJnqcASSYM9ZMSISCZBkIjmQNx4L1+4RSXjU9XfPcjhscc+yd0X7dVN1GC2KEWr/WcMS6HU4GyQawY/LmXfaJ4fahT9+I/KIe/aE4OpxZZUaKJdsMS17F80sYbPrcxBFmD1LoBCw3k3/nAjOW21jbeapV+HLvHa8Qf7jBUN5NaeP4rmIJWCv/6MC2eay7kvgigGe4xx/6wl9KYxc1tSmigb3w8BCpaptfQoQIW2A3Hp/QfZsBQDU3H6DPYMMOTp3h2INcDIH2eedgaPzHmxL7ZiDrjsZKQvVwPqzU/F0BwHIzAfB8qzUEFB0HtgYRZPQfakIF9LnaM3Q== X-YMail-OSG: eBgdd00VM1kU5QjE4TE1DUD65QjwE0u3ZIxF0vBKCOQGM6sYJ8_kwoa1J.3Rvbm 5EEwa.Xzc1dArtIpSvLABfQf9pNuVb0iatpN_3cSs0UZZbbyuzf0tgg.47prMNJnSQaaahLOmGdJ l2Qbql6rfQvr6j40j7rkVhaTiBScT1HnaOZJV4tQ44LknHtZbd4XnTXXWx8L0l7xdOVSOQAuEXZR iWooNfx.y_bno6guHUNt73U8w_vNRtSRuzlPnkQyCcrygZyglKG3Z374D9SidJnmPUoQrrDL2.JY 9Z8ccQgeBTDnr3A9JiXKs1o5IPIYYLgQoegAjYy.zGGdMAexCgdvgwmW5mYc_3_WfvvjoHbVn0LS tRrtYYettktJVd99enSXwsYBMWj6UYUfnKPVh60UH7e64eipy63VnPWZdiJEnfNjRMuaXELNJOur t0z44ThvsWeMElHbf2Lu_q62y901lSS.vt1hawNNa8Hwu.5yJHs0sqI80YSy1I9qO6WOdafhi5wK unaup_Vbfe9eHyx_QtoQxXp6kbW3K0LthSrnb7.RPIkgAFpjUU6NiY3LX6pPYrCPH2nyX8gaBzXB AkYU8dYv55DXJ70er__kQlAdKrHlfeCB7gGZet9YD4gdwX1.Zoh7UZ1zdrvulqkKoPPJgpHdLcuG W.cLaFCfJL_TbBM29chv6EehgpMcHA9mm00rYVwM3ey2BfvBsXlb3LiePzcxLCMoti43.ZzV9iWh iPemnqKJLGl7MStER0yndMsI1J4M892w4jHvc0siV9qkyJFUtaa1b1mH7p5wkd61WFBhaQ90TgUP 1GvnFJolqZYi6NBFxsiSgBplx3XIi8rL2QlBaH4c4R4v82ROIi3KqQJ3ig4nrHOrm1L71R6EeeL. SUWv2hDkU0KX8_7T2TK2fEbu9KpxBiIUqEp7G4boo833c8lGzl3PkN9qozi_mk2TJ7CQI3iJ4bpY r2S6QPIUTZEF2EAsnaj4.Q0Sn7Rh7W2LCA2j.3SU6qcZhHgeL3lBKLADSzF33GrCAIYIiZHU88.K kTU7VM99p5ihS2XWEfYaLmXH4Ybf3ZotzU_nvSYglH1EJv6YNHnXOO8nc5xiOjIFYRB5XF64ofMf 0f49rDsxXU3TDFL_OvNlLJkZ4lY4PyklrFpQ0TT0Icymliua6wp1PVXsbT1.wBAnNkG5.1pcs6RK 8Ato2snEQRU2dIl.ST30kIEvaB_Y2tz_PfyaTi4BRI3gF_kweROLhgqprVjZU5mhOAcpBsnU8J_E biEXYqF6Vdr3KhrrQRopQwh3TXrtDGvCEV1Ccl6SMbp2PdiyjnXYYQcB3JbZYTM50FP3Rpkj6YFg UVC7EvlXB2Ogfd_3b8DMih3lorB64h8MWERQS6e4f5KDYcdAgAOo3NlmVLusxQUJNbHfPZmFye9K __11fKoOso9dMvDYDuzNCdiYflK.9famhmbqr.CZCWk.MmTP3rMblM8IcNOnDlgt6M3GxzPIMgHI frIrAecaa.wBO_AwPUgv4s_S1YrSnQzwoIKAh2uYR.JSFjgFFsqCf5McNPDc2KasiRo8EPFp.JRb 5tCQbMUP4KZT4ar_l8Uz7_wTzU34TEdw28iSK8iMozT2Uy38k45rxNBs49XaP3vr4FBSW.XNrXz4 PVbOHZ.kp43C0UuJQmgifBpxqgjYJnf_UkVk8Tizlb1w_trBdEA683YsZSDPGetbibZoXglumNC6 jtebc7HoFAYeBkdkI_Xtk5X9QUnN9E.ZwPv2LBFP.qRU0woCzMeT3hOSX3TKDkZ6O73sWWSHpKsA ymUNYHM8g_LGpEpcbPqCl_LpBS8YdA.2ftSEOEVJ7a3Y1XViR3JNXzVD0pMf5SZLx1M61wuHjthB KaLCkcS_tllBs24No1uZMHNXaxVPaMT2DjWQbEHdfiQTbl5F3UnjNuj1ZwrPXca6dZ4VxlGo42t4 2Lu.Fp8YYJwz13MSq_VYI_kW4Nclkh8bjGL4usamVRdR3UfVl1wcooInOOrwLCuiEX8tI0QyKN99 jN2hyGevlv1K7hA_RQWoVHazvdId_MdrbIghnLJGuj3ocnixTRDAU2FzVULSpg7eM0Ms2GwWKF9m 2EYzJ2oFOP7axv3eqtEvdvvb19WMrBc_KgR.1sKaVdCHrygj5gAti54oV6P6OLSSbGru1cMZMsRU cEZLEos.Zzd5zgKPpdeRQuYBfT_90BnxpOe8ps5PQY.vhsB_T1aA3fzthNPfEVxgJyZSvUFLrQ68 a_Ojy0Ijc1cTag3s_tOqFv9B6iykIVKsOUyWed75Nt10rHL2_TIC85fDQPXHYzCRfjO6at9ivJPz srYQ- X-Sonic-MF: X-Sonic-ID: 673cea45-eaba-419f-9165-7236e1c58ac4 Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Mon, 3 Jul 2023 07:11:21 +0000 Received: by hermes--production-bf1-5d96b4b9f-8sjv4 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 9a57ce844e4c4400681e95077c52b734; Mon, 03 Jul 2023 07:11:15 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 Date: Mon, 3 Jul 2023 00:11:03 -0700 References: To: khng300@gmail.com, dev-commits-src-main@freebsd.org In-Reply-To: Message-Id: <4729575A-9D5A-462B-9A35-E8B274601215@yahoo.com> X-Mailer: Apple Mail (2.3731.600.7) X-Spamd-Result: default: False [-1.16 / 15.00]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_SPAM_LONG(0.54)[0.544]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MV_CASE(0.50)[]; NEURAL_HAM_MEDIUM(-0.21)[-0.207]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.30:from]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MLMMJ_DEST(0.00)[dev-commits-src-main@freebsd.org]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_NONE(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; DKIM_TRACE(0.00)[yahoo.com:+]; FREEMAIL_TO(0.00)[gmail.com,freebsd.org]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.30:from] X-Rspamd-Queue-Id: 4QvcXq5RLqz3knJ X-Spamd-Bar: - X-ThisMailContainsUnwantedMimeParts: N On Jul 2, 2023, at 09:34, Mark Millard wrote: > Ka Ho Ng wrote on > Date: Sun, 02 Jul 2023 10:18:35 UTC : >=20 > On Sun, Jul 2, 2023 at 6:03=E2=80=AFAM Ka Ho Ng = wrote: >>=20 >>> On Sat, Jul 1, 2023 at 7:13=E2=80=AFPM Konstantin Belousov = >>> wrote: >>>=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. >>>> This is not true. >>>>=20 >>>>>=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. >>>> What are non-active fields? >>>> All fields with implicit initializers >>>> "shall be initialized implicitly the same as >>>> objects that have static storage duration." >>>>=20 >>>> I do not think this is required for padding. >>>>=20 >>> In that case, modspecific_t ms did become 0xaaaaaaaa00000000 on = amd64 if >>> -ftrivial-auto-var-init=3Dpattern was specified. >>>=20 >>>=20 >>>>=20 >>>>> 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 >>>>> MFC with: 2cab2d43b83b >>>>> MFC after: 1 day >>>> Min MFC period is 3 days. >>>>=20 >>>>> Sponsored by: Juniper Networks, Inc. >>>>> Reviewed by: delphij >>>>> Differential Revision: https://reviews.freebsd.org/D40830 >>>>> --- >>>>> sys/kern/kern_syscalls.c | 3 ++- >>>>> 1 file changed, 2 insertions(+), 1 deletion(-) >>>>>=20 >>>>> diff --git a/sys/kern/kern_syscalls.c b/sys/kern/kern_syscalls.c >>>>> index 234e51cfd280..0b51edf5e985 100644 >>>>> --- a/sys/kern/kern_syscalls.c >>>>> +++ b/sys/kern/kern_syscalls.c >>>>> @@ -173,9 +173,10 @@ kern_syscall_module_handler(struct sysent >>>> *sysents, struct module *mod, >>>>> int what, void *arg) >>>>> { >>>>> struct syscall_module_data *data =3D arg; >>>>> - modspecific_t ms =3D { 0 }; >>>>> + modspecific_t ms; >>>>> int error; >>>>>=20 >>>>> + bzero(&ms, sizeof(ms)); >>>>> switch (what) { >>>>> case MOD_LOAD: >>>>> error =3D kern_syscall_register(sysents, data->offset, >>>=20 >>>=20 >>> Ka Ho >>>=20 >> Since I missed the reply-all button just now, I resend this email. >>=20 >> Reading on N2716 one of the footnote stated: >> "Note that aggregate type does not include union type because an = object >> with union type can only contain one member at a time" >>=20 >> And below at 6.7.9.21 only aggregate was mentioned but not union, = which >> matched what I observed with an `cc -ftrivial-auto-var-init=3Dpattern` >> invocation. >=20 > The context for modspecific_t is (looking in my source > tree for main): >=20 > # grep -r modspecific_t /usr/main-src/sys/ | more > /usr/main-src/sys/sys/module.h:} modspecific_t; > /usr/main-src/sys/sys/module.h:void module_setspecific(module_t, = modspecific_t *); > /usr/main-src/sys/sys/module.h: modspecific_t data; > /usr/main-src/sys/kern/kern_module.c: modspecific_t data; = /* module specific data */ > /usr/main-src/sys/kern/kern_module.c:module_setspecific(module_t mod, = modspecific_t *datap) > /usr/main-src/sys/kern/kern_module.c: modspecific_t data; > /usr/main-src/sys/kern/kern_module.c: modspecific_t data; > /usr/main-src/sys/kern/kern_syscalls.c: modspecific_t ms; >=20 > This is C code, not C++ code. The languages are not fully > matching in various details in some similar areas, especially > when the vintages are not from a similar timeframe. Also, > modspecific_t is a union: >=20 > /* > * A module can use this to report module specific data to the user via > * kldstat(2). > */ > typedef union modspecific { > int intval; > u_int uintval; > long longval; > u_long ulongval; > } modspecific_t; >=20 > When I look up C's N2716 in: >=20 > https://www.open-std.org/jtc1/sc22/wg14/www/wg14_document_log.htm >=20 > I find: "N2716 2021/05/09 Tydeman, Numerically equal" with the > link https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2716.htm . > Its summary line is: >=20 > QUOTE > Summary: The phrases "numerically equal" and "numerically equivalent" = are used, but never defined. Also, they seem to add no value to just = "equal". > END QUOTE >=20 > (There is also: "N2847 2021/10/15 Thomas, C23 proposal - Revised > suggested change from N2716" with the link: > https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2847.pdf .) >=20 > This has nothing to do with what you are writing about. >=20 > For C code, I suggest only using C langauge specification > materials, not C++, unless the same source is to have > dual language use for some reason. (I see no indication > of such here. If such use is the intended context, please > be explicit about that.) >=20 > Also, using material from 2021 when FreeBSD is based on a > older C standard version can have its own problems. If I > remember right, FreeBSD is basically targeting C11 or > so for its C code. >=20 > An example quote from footnote 310 (for memcmp) in ISO/IEC > 9899:2011 is: >=20 > QUOTE > The contents of "holes" used as padding for purposes of > alignment within structure objects are indeterminate. > Strings shorter than the allocated space and unions may > also cause problems in comparison. > END QUOTE >=20 > Initializing .intval and then accessing .ulongval resulting > in 0xaaaaaaaa00000000 as a possible result should be no > surprise for C as far as I can tell. Based on what I'm > reading, code that assumes otherwise is incorrect relative > to the C language standard. >=20 > It looks to me like the bzero use is trying to make changes > to allow non-standard C code "still work". I missed the relationship between the earlier: git: 2cab2d43b83b - main - syscalls: fix modspecific_t stack content = leak and: git: 005aa1743b42 - main - modules: bzero the modspecific_t and so did not comment on the implications in that direction. One could read my notes as indicating that the bzero is inappropriate to the memory content leak. What I wrote instead supports use of bzero (or some such) for avoiding memory content leaks. For: typedef union modspecific { int intval; u_int uintval; long longval; u_long ulongval; } modspecific_t; Code like: { . . . modspecific_t ms =3D { 0 }; . . . assigns to .intval and falls under what I quoted about "holes" and such. Also, ISO/IEC 9899:2011's explicit list of unspecified behavior in J.1 Unspecified behavior reports: -- The value of padding bytes when storing values in structures or unions (6.2.6.1) -- The values of bytes that correspond to union members other than the one last stored into (6.2.6.1) "modspecific_t ms =3D { 0 };" stores specifically into intval under the language standard's rules, and there are bytes in longval and ulongval that are not in intval on at least some platforms for FreeBSD. Thus the language standard indicates that assignment leaves the values of various bytes in the union unspecified --and that allows the leak of some stack content as a possibility. The bzero avoids that. Sorry if I caused any confusion with my to narrow of a focus. =3D=3D=3D Mark Millard marklmi at yahoo.com