From nobody Sat Jan 11 19:52:18 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 4YVq1Y0lnrz4rh5P for ; Sat, 11 Jan 2025 19:52:33 +0000 (UTC) (envelope-from jrtc27@jrtc27.com) Received: from mail-wm1-f54.google.com (mail-wm1-f54.google.com [209.85.128.54]) (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 4YVq1X656Qz48lH for ; Sat, 11 Jan 2025 19:52:32 +0000 (UTC) (envelope-from jrtc27@jrtc27.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-wm1-f54.google.com with SMTP id 5b1f17b1804b1-435f8f29f8aso22522275e9.2 for ; Sat, 11 Jan 2025 11:52:32 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736625151; x=1737229951; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=mRHPjdl8VJScUybkgDGkAPDEVdTHjjFSSywYsa9IBPA=; b=MydnKcoPnlMj0UN4LRCHP1dJMDS4H++6Futxt4b1FCSqsDs6ip19wEPWtVos111hGi fVKo6nGtbR19vWOqY4WZ20QuI5kHqCVBph5XVhoQAdR1QslK0qWUcPM7bs1zqxKYnI8Z CH4hCoYf42vQnUFMjRRmLVMSk4Y7OvPAVjWzbkv0pbOng41AY2cnHdlA6a2i72A2IgKH Y3HdzgfB4GGLG3FtjNxHquizF+LubTuqV3iVqmVZ9vHZUUNFQOiZAso4CJe26fq+LnoW sWe2T56O9xgdoNeURAtEMUVV9W7TttzC8Pc3r6sNSDKHq6ZRvyoUfUZBJrfrC8wL2br3 6AAw== X-Gm-Message-State: AOJu0YxgFutwnvd9gCyW2aMB9aNWJYLMSTn9MwdHFVunbNRJTl+7R/l6 kAkH2Cnj5lhnPvZAK+YOmUqHPhc3+LMV9SO0la/rG1FCKkOZ43VYGg+Ed7lTwWw= X-Gm-Gg: ASbGncupRtPhYSjEACOey74FOpvwARxQPZjAlM587kUpSnoBle5JNtTt6R59ce8TMD3 5bTNq+wBGy6h5K4YBGugxgkXgacmo1y7gg5gKIcaTW0y8r0pU3pDA0MWDvd4Mg5oif9U/QGFS6o hxSZUp6oX4dFp/b04iNBNBL0QVKOYFDbeuZ5KyEWB7+Ptz/9nd54Nap7kBdLw0besv6zD+0aH9y ULb74z+NZ75uC7IaBgJytBqVtB8UjZP7IcId/aOsJFgJG2KN+TaQj1bRFPMvNeNNyjT3Is= X-Google-Smtp-Source: AGHT+IFtYh7hrZ/KOttL8ypppFdt5BpSryp8SfDp8hQM0pdygoEItoHLqwJjNUxNz7rCH+dCzoOTWQ== X-Received: by 2002:a05:600c:3588:b0:434:fdbc:5cf7 with SMTP id 5b1f17b1804b1-436e26f4aecmr125040435e9.27.1736625151020; Sat, 11 Jan 2025 11:52:31 -0800 (PST) Received: from smtpclient.apple ([131.111.5.201]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-436e2dc05a1sm126969265e9.15.2025.01.11.11.52.29 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 11 Jan 2025 11:52:30 -0800 (PST) Content-Type: text/plain; charset=utf-8 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 (Mac OS X Mail 16.0 \(3826.300.87.4.3\)) Subject: Re: Setting a default value for OPT_INIT_ALL (stable=zero, current=pattern) From: Jessica Clarke In-Reply-To: Date: Sat, 11 Jan 2025 19:52:18 +0000 Cc: Freebsd Arch Content-Transfer-Encoding: quoted-printable Message-Id: <97E3DD11-0F63-4EF2-8CC9-DAAF8BC9CE1C@freebsd.org> References: To: Alexander Leidinger X-Mailer: Apple Mail (2.3826.300.87.4.3) X-Rspamd-Queue-Id: 4YVq1X656Qz48lH 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:15169, ipnet:209.85.128.0/17, country:US] On 11 Jan 2025, at 19:43, Alexander Leidinger = wrote: >=20 > Hi, >=20 > 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=3DCHOICE' > Initialize automatic variables with either a pattern or with = zeroes > 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 = values > 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 = accident. >=20 > 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. >=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.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=E2=80=99re concerned with) there=E2=80=99s a ~70% overhead for 458.sjeng with the = train workload. This may not be particularly widespread, but the fact that it shows up for such a standard benchmark is concerning, so, whilst we do think that stack zeroing is generally a good idea, there=E2=80=99s some toolchain work still to be done in order to deploy it by default. Jess NB: As far as I know the nature of the performance regression is not tied to the specific LLVM backend, so should show up on amd64 too, but have not tested it (and the exact effects of the generated code will vary across systems anyway)