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

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
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.

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)