From nobody Sun Jan 12 11:51:34 2025 X-Original-To: freebsd-arch@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 4YWDKM3v2cz5kXyc for ; Sun, 12 Jan 2025 11:52:39 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Received: from mailgate.Leidinger.net (mailgate.leidinger.net [IPv6:2a00:1828:2000:313::1:5]) (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-signature ECDSA (P-256) client-digest SHA256) (Client CN "mailgate.leidinger.net", Issuer "E6" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4YWDKM0m4Lz4THw; Sun, 12 Jan 2025 11:52:39 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Authentication-Results: mx1.freebsd.org; none List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@FreeBSD.org MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net; s=outgoing-alex; t=1736682753; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=VfDHdoEv/pEoP03UYdtjItUWXXz6TSvpN1g2DR9BuFg=; b=Zf+dstCItb6XYJbjFN74Pw3uj68aBG7J+A2MjhqoDUKyShet0Uu/8A7lSlKO69nWWcas3B b1AhFEkqL+Cvhclv4OsqAWiyVJi3z5csX3nARjKbZVcbsHMGfzAjoMEYlLDQGWHDrYKAbr EywObWWyT4C0Xp4a4yfLqv/Z3YgfxO1bhNBYGcFVBFKXtfaU4HQ+SLuVXHulATrrwKdh/u E78V8IfzzLTo8XNi3n8mSWjNH1ZwJ7O5URCgXeZ1w5fBixiJfYQJgSNTD9UCb94LQmlXPz QSj4x+XAxNlcHRcXbWKeF6LUgQwHpTlO50qdX5mEQQJ8v4rAKh+Lm1r/7YkWcg== Date: Sun, 12 Jan 2025 12:51:34 +0100 From: Alexander Leidinger To: Jessica Clarke Cc: Freebsd Arch Subject: Re: Setting a default value for OPT_INIT_ALL (stable=zero, current=pattern) In-Reply-To: <97E3DD11-0F63-4EF2-8CC9-DAAF8BC9CE1C@freebsd.org> References: <97E3DD11-0F63-4EF2-8CC9-DAAF8BC9CE1C@freebsd.org> Message-ID: <269527c32f9d9458d4497674fc458c69@Leidinger.net> Organization: No organization, this is a private message. Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="=_51a700ab4946ca959be1051266d6d751"; micalg=pgp-sha256 X-Rspamd-Queue-Id: 4YWDKM0m4Lz4THw X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:34240, ipnet:2a00:1828::/32, country:DE] This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --=_51a700ab4946ca959be1051266d6d751 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8; format=flowed Am 2025-01-11 20:52, schrieb Jessica Clarke: > On 11 Jan 2025, at 19:43, Alexander Leidinger > wrote: >> >> Hi, >> >> we have support to set a default initialization value for >> uninitialized variables (OPT_INIT_ALL in src.conf). Possible values >> are (copy&paste from >> https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565514.html): >> '-ftrivial-auto-var-init=CHOICE' >> Initialize automatic variables with either a pattern or with >> zeroes >> to increase program security by preventing uninitialized memory >> disclosure and use. >> >> The three values of CHOICE are: >> >> * 'uninitialized' doesn't initialize any automatic variables. >> This is C and C++'s default. >> >> * 'pattern' Initialize automatic variables with values which >> will likely transform logic bugs into crashes down the line, >> are easily recognized in a crash dump and without being >> values >> that programmers can rely on for useful program semantics. >> The values used for pattern initialization might be changed >> in >> the future. >> >> * 'zero' Initialize automatic variables with zeroes. >> >> The default is 'uninitialized'. >> >> The main point of this option is to prevent leaking random data by >> accident. >> >> What I propose is to have OPT_INIT_ALL set to "zero" in stable >> branches. We could maybe also set it to "pattern" in -current. In my >> opinion this a similar thing like the malloc production setting, or >> witness, and so on. >> >> Any thoughts about this? >> >> In case of a generic consensus of this, I would expect the release >> engineering team to take this into their procedure for branching a new >> stable branch. The locations where a OPT_INIT_ALL?=zero would need to >> be added are share/mk/bsd.lib.mk, share/mk/bsd.prog.mk and >> sys/conf/kern.mk. > > Unfortunately in our testing we have seen that LLVM can have serious > performance regressions in some cases. We wanted to enable set it to > zero in CheriBSD, but could not due to this. This showed up in one of > the SPECint CPU2006 benchmark; when testing on arm64 (what we’re > concerned with) there’s a ~70% overhead for 458.sjeng with the train > workload. This may not be particularly widespread, but the fact that it Was the benchmark compiled with =zero, or CheriBSD, or both? Any chance to trace it down to a particular location, in case the benchmark was not compiled with =zero? > shows up for such a standard benchmark is concerning, so, whilst we do > think that stack zeroing is generally a good idea, there’s some > toolchain work still to be done in order to deploy it by default. Was this only tested with LLVM, or also with GCC? Same issue? Is the LLVM community aware of this / any bug tracker issue for this with upstream? Bye, Alexander. -- http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_51a700ab4946ca959be1051266d6d751 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc; size=833 Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmeDrNUACgkQEg2wmwP4 2Ibo+g//VzCqx8aNRkteRLr/6XgXIm26asoXedT8YLN6Ppbeu43r1khkvzwnkYEd HM47FkeMawZRvWMtxrgEouOLBnXvX25x/cJLxwLJHGwBgsjHFS79PrSnktJnccjh fe9j2kFI7iGXUmloSwsgIGgfwMYQURi+IIP3r2Z8VoWu6b4QtVBrKprWw3oxhqea lsJaLAsYlk0m9LgfLYbZjThnuXJxHbQPdAZxEgs75sWrz25AZL1dOzilQWoPk08F 2h7QZ4XF4GVYnbtdJuh4av1g/OFNgtjmyIQbYOV61ghXG4Y4JJYxB92MjSUKu0xG ca7fqNDRJnxsOHUxEgGrxJRwkNrrzXIhOY2VJzWtcR3/YfOuecuGaooZMOiEniKl C/P8Q3FqopXNszqBPc7i39wh4O5Azf2XVw/xURw9kn1cgZYQrYns9au2MTUkJ5lo TFud0vOmMEWWerZIx4oCNcKiHJ7Wk1d8N2n0Cu7KzpodVmr5ZCzF/zUvhge06Opk eQJIl5DrGqBCm46vh3ay2IRxzDtdlQQS9DHhZjXgKPx1s7CPQvvlOI0L+jALU8F8 qBCmfBUebiYUL0X1a30y0ZM14NxTEd7RE8c+Vb6MmaieYYOZMLTZkCnSJIR/CYzn fr9t8fxFW4Luc2JTnxgZZttkewpzl0KckI2eIVGeEcG+uanVHZ4= =HG+T -----END PGP SIGNATURE----- --=_51a700ab4946ca959be1051266d6d751--