From nobody Tue Jan 14 18:24:59 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 4YXcxC00prz5kG6M for ; Tue, 14 Jan 2025 18:25:03 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4YXcxB1bs9z476N for ; Tue, 14 Jan 2025 18:25:02 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=hardenedbsd.org header.s=google header.b=jhVbJSi6; spf=pass (mx1.freebsd.org: domain of shawn.webb@hardenedbsd.org designates 2607:f8b0:4864:20::132 as permitted sender) smtp.mailfrom=shawn.webb@hardenedbsd.org; dmarc=none Received: by mail-il1-x132.google.com with SMTP id e9e14a558f8ab-3a8180205f3so291605ab.0 for ; Tue, 14 Jan 2025 10:25:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; t=1736879100; x=1737483900; darn=freebsd.org; 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=RVo21DohWUElTdjDup69qUSW7TDVA1Nr1C4yJIwFWpc=; b=jhVbJSi6FlMCSPAj8BJMpEcCFY5sMVlJJcjIdRihnTdMhI8lY8FoKNCGI2FBjq1NaS z40TNDRlXna/FD1W+WNBM7mgskw6Ryp3bDrBw38WAExrVe4vO4vcU7kkRRCsHI2lP4MS jfD9U3RVlOq9PxFi2mjUD1vFaKvCsZUiL8zHvuxTBSzzf3JOWhJ7/z+oVRLsRVgioLKq Z6FIMv/mWOBGeCNq2pqwoUhyc0y2y3YM0VMfOBgG2BPirzdd/ST8iLXiB8aniNner1sq 85+elZqns9As6Aseph6ERDtdQKzYTljtHqQywd9fE0mM2XcV/2JN04zxEXITv2/dI/ek HA2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736879100; x=1737483900; 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=RVo21DohWUElTdjDup69qUSW7TDVA1Nr1C4yJIwFWpc=; b=vLsSWVkrrJqrwtfsLEFXQb1zuzvN4hH/3Yz9+dgp07YfeyA9sKGvBskCUwesRwgwOw HaZOmHUyaFL0tOHZg7Qhk6F67mltFPg92einMf+1Yqd2GynMyjGFg9i4G7WxwPEEfOEM cOvh3sk78mByCseigk5hNhnNkrP747HhvT8Vi1CZ0nscKI9rmtKqWOEiJw8BYxst6x75 QGnFWYEzzcSLldLmc4HiCfasVAfvY+iZcAJ2dOHX/kF5vbbtHwoHDor6cXV6UpYI2e8S +pm2TpfguH6XEyD+sb5S4eSgv8CMqvpFKgnhQbQ+vqG6UYUIp0+jSHb1KFq8tgldB78j omTw== X-Gm-Message-State: AOJu0Yx8V0XXJxYk/tminmmHZZQhCbC8NBLLvkzCyAbYTZBGPvDWDTJy WrzGE+WQIDN/7Jqw5C+spwJdufWkhrcwxjnWZ0kAxXZNG0vP2PwiFv/6TdDZAi8gDKoFD/z9a+/ A X-Gm-Gg: ASbGncsBUZn7mvJsgAjWhsJrUEEzKaYAVvzQS/6ULPhcAI5hnub3v7qFOFX7K8Qy3Mc voIeG+UgqtU+3qq8U+UX93gOEgfiRL4GHlshZ/ryzpNzQYCaGSleygZOyhHHlk1Ero71BVQ1EQ2 hXDOImEgkIxD6WWwcR4Rna+wgY99iY3OYRgjLuHE2TlFdfw8zixDZJfEu4DvFQ/v2KBYlOd/xx5 4gE05Qu/otjHrcZsAG3BP0P60VcsImPLNdz40M= X-Google-Smtp-Source: AGHT+IGSFSREqQG36bqSI0DnghiorBoi7mDGKum8Tb0bkgydrAjjy1R+whOMca4Aon4xPo418X1DPw== X-Received: by 2002:a92:c98e:0:b0:3ce:3541:d80f with SMTP id e9e14a558f8ab-3ce8485cc3bmr459035ab.0.1736879100446; Tue, 14 Jan 2025 10:25:00 -0800 (PST) Received: from mutt-hbsd ([2001:470:4001:1::95]) by smtp.gmail.com with ESMTPSA id 8926c6da1cb9f-4ea1b6293fbsm3521622173.68.2025.01.14.10.24.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Jan 2025 10:24:59 -0800 (PST) Date: Tue, 14 Jan 2025 18:24:59 +0000 From: Shawn Webb To: Alexander Leidinger Cc: Freebsd Arch Subject: Re: Setting a default value for OPT_INIT_ALL (stable=zero, current=pattern) Message-ID: X-Operating-System: FreeBSD mutt-hbsd 14.2-STABLE-HBSD FreeBSD 14.2-STABLE-HBSD HARDENEDBSD-14-STABLE amd64 X-PGP-Key: https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/blob/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc References: 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 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="743n75b4hxi525py" Content-Disposition: inline In-Reply-To: X-Spamd-Result: default: False [-4.09 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.991]; MID_RHS_NOT_FQDN(0.50)[]; R_DKIM_ALLOW(-0.20)[hardenedbsd.org:s=google]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; MISSING_XM_UA(0.00)[]; DMARC_NA(0.00)[hardenedbsd.org]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::132:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; DKIM_TRACE(0.00)[hardenedbsd.org:+] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4YXcxB1bs9z476N --743n75b4hxi525py Content-Type: text/plain; protected-headers=v1; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: Setting a default value for OPT_INIT_ALL (stable=zero, current=pattern) MIME-Version: 1.0 On Sat, Jan 11, 2025 at 08:44:47PM +0000, Shawn Webb wrote: > On Sat, Jan 11, 2025 at 08:18:27PM +0000, Shawn Webb wrote: > > On Sat, Jan 11, 2025 at 08:43:13PM +0100, Alexander Leidinger wrote: > > > Hi, > > >=20 > > > we have support to set a default initialization value for uninitializ= ed > > > 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=3DCHOICE' > > > Initialize automatic variables with either a pattern or with zer= oes > > > to increase program security by preventing uninitialized memory > > > disclosure and use. > > >=20 > > > The three values of CHOICE are: > > >=20 > > > * 'uninitialized' doesn't initialize any automatic variables. > > > This is C and C++'s default. > > >=20 > > > * '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 val= ues > > > that programmers can rely on for useful program semantics. > > > The values used for pattern initialization might be changed= in > > > the future. > > >=20 > > > * 'zero' Initialize automatic variables with zeroes. > > >=20 > > > The default is 'uninitialized'. > > >=20 > > > The main point of this option is to prevent leaking random data by ac= cident. > > >=20 > > > What I propose is to have OPT_INIT_ALL set to "zero" in stable branch= es. 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. > > >=20 > > > Any thoughts about this? > > >=20 > > > 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?=3Dzero would need = to be > > > added are share/mk/bsd.lib.mk, share/mk/bsd.prog.mk and sys/conf/kern= =2Emk. > >=20 > > Hey Alex, > >=20 > > To give some additional data points coming from the HardenedBSD side: > >=20 > > 1. In 2019, we added support for this feature on an opt-in basis. > > * Commit 6b573e328baa44bf8b47d40ff72fc1cc8a86fb00 > > 2. In 2021, we enabled -ftrivial-auto-var-init=3Dzero by default. > > * Commit e4494782e5015da340106ca81445c65121c55ae3 > > 3. In 2022, we modified clang itself to enable it by default. > > * Commit 7557c8fd656c83a21e4d43071ea502445efb1ef3 > > 4. In 2023, we added support for kernel modules to opt-in. > > * Commit dd21b931eca8e5370a6d0341908316538b52de71 > >=20 > > The following kernel modules have opted in: > >=20 > > 1. netlink (commit 10aa23df4d0ef6a527b1f2d2092126175f64899f) > > 2. virtio-net (commit c9a07fd0d828e4a8d0ee32f2143cca8e3eb55e8c) > > 3. zfs (commit fdabd703d9870b00c34837299253423ab4fa8ad6) > > 4. iwlwifi (commit 96d935f2f7328b3e2be0ceb557f09e7d2f9a9ea9) > > 5. linuxkpi (commit 803b838923ff76660ae9f5e25696725e77deb274) > > 6. tmpfs (commit 2e5d303a25c030664a6cbf2efd10de29de0da600) > > 7. tarfs (commit c08174516b33c58a771c46a17d94c2ba9ed4f1a0) > > 8. geli (commit 94ee2b3faa4712bd57f3cd82fe442b883a79b68a) > > 9. pf (commit bd836619adb5b502c594dfab0df98e40f8adefe2) > > 10. pfsync (commit a69ea2297d85a9537d2a08d4e4011d3e834b2cba) > > 11. pflog (commit 0ec32fb1fd6062ca9e185e73316ff06a26a1d7af) > > 12. vmm (commit 50d5dbec1c82cc568e0a621e4e405de7ec73b921) > > 13. fusefs (commit 3e58a69c9b83380d77ea432e58868a0b0f3c8374) >=20 > I forgot to mention the ports tree. We ported src commit > 7557c8fd656c83a21e4d43071ea502445efb1ef3 to: >=20 > 1. devel/llvm17 (commit 9127ee56f7ab79886b41733673550e38ca4aa96f) > 2. devel/llvm18 (commit 9f203a68036261ed856182d15c0998c24d866066) > 3. devel/llvm19 (commit 491ae9b6db623db60f3a8dd2e68a9ddbca7c14d7) >=20 > So ports built either with llvm-from-base or llvm{17,18,19}-from-ports > are automatically built with -ftrivial-var-auto-init=3Dzero. This > provides rather significant coverage between src and ports. Today, a vulnerability announcement against rsync demonstrates the effectiveness of -ftrivial-auto-var-init=3Dzero: https://kb.cert.org/vuls/id/952657 rsync CVE-2024-12085 is fully mitigated through the use of that compiler flag. Really cool to see a tangible example of compiler-based mitigations in the real world. Thanks, --=20 Shawn Webb Cofounder / Security Engineer HardenedBSD Tor-ified Signal: +1 303-901-1600 / shawn_webb_opsec.50 https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A= 4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc --743n75b4hxi525py Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAmeGq/QACgkQ/y5nonf4 4fpoqQ/+JItE1ArH8NLBRAvG7wcJB2yLcelmBDuUsrVOtmkbSIXMr/CS9ZFjp59G 2cSHRyWsFmRo6XlLQdBCtqcEmOUlddnBlSXnEf2v4q96rzbWPAlJIEuhf50Ii9cP KP+L9zfUm6Pcnjjt97NG6phUoYfJ1bbXxNBsxrpU+iu9vUyoHGS6roncUvYmBvET LUKzGuKgxW4eSLUfgB8LdkQDKnKkMv9wYL092jA8ldr7P2QHihTm3/z2XE2bGNVJ 2wxnyzVrhn9ppBFmNARU8KVNMCEwK4Cf2IYhUL3BglaZ4xTQ2bacD+Dd/pwwnvPR PNMhK22BWXZa8QGg+v4gxFLCObMBcju3+bZdjkoYnD+ahYezWpIU/f0VEuJXq+Hj rXYSpHrxhwbcJ/s+3jQAWrliXDt/nH0Uo6xJsqzYAj3fQVMJxugrox3r5W99rJmY lBFyraCfpHgUL7BuBQ/ZWq8RkOjAO+IYyjKM4hP5Ln8TBzD8YE9JebF4EZHaQ3Bc FCKlmRoiNzqTRMwoDZQj1Y39tAxV/DbFxb1nOqUMs7pMd2G5yUnaCsmNks9P2bSD Gipl69tzhbxfEG6awJnRCmF8r3Zuu69PAvHEnRvQu9HaEe870qgCeneSihrAxFYW wt+FNhzsfqS57rwusgTXCmIS0d1E53bA/VfZpSSGWsoNdazZWF0= =m7EV -----END PGP SIGNATURE----- --743n75b4hxi525py-- From nobody Wed Jan 15 14:01:04 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 4YY72q0nF1z5lPyv for ; Wed, 15 Jan 2025 14:01: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 (prime256v1) client-digest SHA256) (Client CN "mailgate.leidinger.net", Issuer "E6" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4YY72n6g2Bz3cCF for ; Wed, 15 Jan 2025 14:01:37 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=leidinger.net header.s=outgoing-alex header.b=iYjcAmh8; spf=pass (mx1.freebsd.org: domain of Alexander@Leidinger.net designates 2a00:1828:2000:313::1:5 as permitted sender) smtp.mailfrom=Alexander@Leidinger.net; dmarc=pass (policy=quarantine) header.from=leidinger.net 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=1736949686; 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=7ZRSXJR9k54HCdiNAg0N7aMnx6XTrJjx/SfBfDm3LI4=; b=iYjcAmh80vWrS1Klx3JuNDArlq4xsf4FCkUuE/BvJQ0ih3XHvLvrqIBgNNHXVAA2WuLV7w W3XbwjiGkQcXM93quryxqWbiAeJ0Z2eqMZtsGJSu5/DM2KtUWlZNS2eKHCOje1wxynqRpy 5T+8rjbMqRJBGiiO1hGyDJBdiHzwINOLAp/l0j/nw0Jwqxguil3kAVUvTZU1DZucIdA76/ Cx/B4jH//LC7o3oVD0mxnLH6JwLQjbosn9v7tpw76kyjwIQgdVrlkiEO5Qg+qg7UdR/3JM oAH0aiLWlNzfc15gtXdgvYpjUwILriGWZyXShN7euPJZGhv7Gp8KSvg4Np2orQ== Date: Wed, 15 Jan 2025 15:01:04 +0100 From: Alexander Leidinger To: Shawn Webb Cc: Freebsd Arch Subject: Re: Setting a default value for OPT_INIT_ALL (stable=zero, current=pattern) In-Reply-To: References: Message-ID: <183c74710033af32aa4bde9e7df37e84@Leidinger.net> Organization: No organization, this is a private message. Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="=_88751eaad5e729bbec2b33801b563f1c"; micalg=pgp-sha256 X-Spamd-Result: default: False [-6.10 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.996]; DMARC_POLICY_ALLOW(-0.50)[leidinger.net,quarantine]; R_DKIM_ALLOW(-0.20)[leidinger.net:s=outgoing-alex]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; R_SPF_ALLOW(-0.20)[+mx]; ARC_NA(0.00)[]; ASN(0.00)[asn:34240, ipnet:2a00:1828::/32, country:DE]; MIME_TRACE(0.00)[0:+,1:+,2:~]; HAS_ORG_HEADER(0.00)[]; MISSING_XM_UA(0.00)[]; DKIM_TRACE(0.00)[leidinger.net:+]; MID_RHS_MATCH_FROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_ZERO(0.00)[0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; TO_DN_ALL(0.00)[]; HAS_ATTACHMENT(0.00)[] X-Spamd-Bar: ------ X-Rspamd-Queue-Id: 4YY72n6g2Bz3cCF This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --=_88751eaad5e729bbec2b33801b563f1c Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Am 2025-01-12 19:05, schrieb Shawn Webb: > On Sun, Jan 12, 2025 at 01:06:06PM +0100, Alexander Leidinger wrote: >> I have most of the kernel stuff as modules, so this should all be >> compiled >> with =zero (except the isal and nvidia modules, I have just >> compiled-tested >> the ports I use but not yet run tested with a similar feature for the >> ports >> collection): >> Id Name >> 1 kernel >> 2 opensolaris.ko >> 3 usbhid.ko >> 4 hidbus.ko >> 5 hid.ko >> 6 kbdmux.ko >> 7 coretemp.ko >> 8 hsctrl.ko >> 9 hidmap.ko >> 10 tcphpts.ko >> 11 ahci.ko >> 12 hcons.ko >> 13 if_igb.ko >> 14 iflib.ko >> 15 cryptodev.ko >> 16 cc_chd.ko >> 17 aesni.ko >> 18 tcp_rack.ko >> 19 nvme.ko >> 20 smbios.ko >> 21 efirt.ko >> 22 vkbd.ko >> 23 zfs.ko >> 24 xdr.ko >> 25 cpufreq.ko >> 26 dpms.ko >> 27 hkbd.ko >> 28 umass.ko >> 29 miibus.ko >> 30 geom_eli.ko >> 31 geom_label.ko >> 32 tmpfs.ko >> 33 fdescfs.ko >> 34 if_bridge.ko >> 35 bridgestp.ko >> 36 if_epair.ko >> 37 xhci.ko >> 38 firewire.ko >> 39 if_fwip.ko >> 40 filemon.ko >> 41 sound.ko >> 42 ulpt.ko >> 43 accf_dns.ko >> 44 accf_data.ko >> 45 accf_http.ko >> 46 accf_tls.ko >> 47 cpuctl.ko >> 48 tpm.ko >> 49 ipmi.ko >> 50 linux.ko >> 51 mqueuefs.ko >> 52 linux_common.ko >> 53 linux64.ko >> 54 nullfs.ko >> 55 cuse.ko >> 56 isal.ko >> 57 nvidia-modeset.ko >> 58 nvidia.ko >> 59 hms.ko >> 60 ioat.ko >> 61 snd_uaudio.ko >> 62 pf.ko >> 63 procfs.ko >> 64 pseudofs.ko >> 65 linprocfs.ko >> 66 linsysfs.ko > > I would especially be curious about crypto and platform (like EFIRT) > kernel modules. If you do enable trivial variable auto-init for any of > what you listed, please let me know which ones work. I rebooted the system yesterday, so the stats are just about the last 18h: # sysctl kern.ipc.tls.stats kern.ipc.tls.stats.ocf.retries: 0 kern.ipc.tls.stats.ocf.separate_output: 105 kern.ipc.tls.stats.ocf.inplace: 61464 kern.ipc.tls.stats.ocf.tls13_chacha20_encrypts: 2 kern.ipc.tls.stats.ocf.tls13_chacha20_decrypts: 0 kern.ipc.tls.stats.ocf.tls13_gcm_recrypts: 0 kern.ipc.tls.stats.ocf.tls13_gcm_encrypts: 61484 kern.ipc.tls.stats.ocf.tls13_gcm_decrypts: 56742 kern.ipc.tls.stats.ocf.tls12_chacha20_encrypts: 1 kern.ipc.tls.stats.ocf.tls12_chacha20_decrypts: 0 kern.ipc.tls.stats.ocf.tls12_gcm_recrypts: 0 kern.ipc.tls.stats.ocf.tls12_gcm_encrypts: 82 kern.ipc.tls.stats.ocf.tls12_gcm_decrypts: 48 kern.ipc.tls.stats.ocf.tls11_cbc_encrypts: 0 kern.ipc.tls.stats.ocf.tls11_cbc_decrypts: 0 kern.ipc.tls.stats.ocf.tls10_cbc_encrypts: 0 kern.ipc.tls.stats.destroy_task: 0 kern.ipc.tls.stats.ifnet_disable_ok: 0 kern.ipc.tls.stats.ifnet_disable_failed: 0 kern.ipc.tls.stats.switch_failed: 0 kern.ipc.tls.stats.switch_to_sw: 0 kern.ipc.tls.stats.switch_to_ifnet: 0 kern.ipc.tls.stats.failed_crypto: 0 kern.ipc.tls.stats.corrupted_records: 0 kern.ipc.tls.stats.active: 20 kern.ipc.tls.stats.enable_calls: 4824 kern.ipc.tls.stats.offload_total: 4824 kern.ipc.tls.stats.sw_rx_inqueue: 0 kern.ipc.tls.stats.sw_tx_inqueue: 0 kern.ipc.tls.stats.sw_tx_pending: 0 kern.ipc.tls.stats.threads: 24 This looks to me like crypto works with =zero (or my reading of kern.mk is wrong with OPT_INIT_ALL=zero in src.conf, or kmod.mk needs a similar piece of handling this if it is not picked up from kern.mk in module builds). The above list of modules is the live system. linux, efi (the board is supposed to have it, but switching from bios to EFI fails, the issue may be in front of the keyboard), cuse, firewire, tpm, ioat (if nothing uses it automatically when autoloaded by devd) are not in active use, umass, ulpt, sound not yet tested, nvidia and isal are not recompiled yet. So far I have not seen issues. Is someone out there with access to the SPECint CPU2006 benchmark who can do some tests to drill down what may be the reason for the slow-down of 458.sjeng (first question is: is there a slow-down if the bnechmark is not compiled with =zero and the world and kernel are build with =zero, second question would be to profile and check where the degradation happens)? If the degradation doesn't happen when the benchmark is not compiled with =zero, of if it happens in our code and we can fix it, we could go ahead and give the =zero a try on -current before applying it in -stable. Bye, Alexander. -- http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_88751eaad5e729bbec2b33801b563f1c Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc; size=833 Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmeHv7IACgkQEg2wmwP4 2IavTRAAm/eunmvQczOMpO7eksovT7I8oGgTTP4Fy3WeqWPsV02cU6V59n3TZoxb ZgQmbmkIsdhoPhetjT2uQX3dl0KkO6Be+RMvWFLGQOU1nJNblyy8kbmywAdHmlUG o7sw0tdmYLNoFCG6KEJy1TcK8FN1ziD9WDz3kz4hjRRSVOrZ8474h7DjShTyfrRJ KPTG3NUGgII1lGa4CkZG81ksLdAVQwiV2fF7R9/pdFCi/B3t/HW+amkfxq7/hkRb tS6i6n22qpmkcVwvE1qwNMzABxeBYVzjCLfBz2AxUJ4jWqorE5Bn6CPciE1KNtJV bVjc+QyIXan9krSnUoJosPDwli4oYhwuspyW52TdOX5bvUzwVdgn070cTqz39zL5 x3Cho//bCNJrQ6dGM3qb9r5V3eNEbaPotk2jDwvg+h1DZ5DE5Lpgf6Exg9GRKfh4 1LmkvHe6mHW7xvtPj5nFWyayA0QsJHPlAQDvTyl0PGVnFAgtWbj3qptX/6xQ0xNA 5I6BYTOHFBnU7ixiWhw/VjN91maNrNQvYzrNg1BCnAzF1Jo3xR/di/UtMSEZC0eL qUHRDrR+/FmAqy5S0nQkiuKIMMbxOTJGDgAtZjZPUBjocEefhv6SMpGRbtx5T8RG Ppn2n4IRUCIlcZuyQwNjaVVGMdviS8Vp6X5Sg/aCKKcv1TBQ1GY= =iQrs -----END PGP SIGNATURE----- --=_88751eaad5e729bbec2b33801b563f1c--