Re: Setting a default value for OPT_INIT_ALL (stable=zero, current=pattern)

Am 2025-01-11 20:52, schrieb Jessica Clarke:
> On 11 Jan 2025, at 19:43, Alexander Leidinger <Alexander@Leidinger.net> 
> 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