linux-kernel - RE: [PATCH v2] ACPI/IORT: Fix GCC 12 warning

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <f11f91706c704a72b593a183f33ff456@AcuMS.aculab.com>
Date:   Sun, 13 Feb 2022 03:33:44 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Kees Cook' <keescook@...omium.org>,
        Robin Murphy <robin.murphy@....com>
CC:     Ard Biesheuvel <ardb@...nel.org>,
        Victor Erminpour <victor.erminpour@...cle.com>,
        Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
        Hanjun Guo <guohanjun@...wei.com>,
        Sudeep Holla <sudeep.holla@....com>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Len Brown <lenb@...nel.org>,
        "ACPI Devel Maling List" <linux-acpi@...r.kernel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "trivial@...nel.org" <trivial@...nel.org>
Subject: RE: [PATCH v2] ACPI/IORT: Fix GCC 12 warning

From: Kees Cook
> Sent: 12 February 2022 00:38
....
> 
> Sure. I think I am trying to take a pragmatic approach here, which is
> that gaining auto-var-init is a big deal (killing entire classes of
> vulnerabilities), but it comes with an annoying compiler bug (that we do
> get a warning about) for an uncommon code pattern that is easy to fix.

My worry about the compiler setting variables to zero is that people
will get lazy and assume it happens.
Then some code will get compiled without that enabled (possibly because
it slows things down too much) and then really horrid bugs start to appear.

If the intent is to detect code that is failing to initialise locals
then setting to a non-zero value (that is likely to cause grief)
is much better than setting to zero.

I'm particularly worried if the compiler starts to zero on-stack arrays.
There is plenty of userspace code that will use char buff[MAX_PATH]
to build a filename or char errmsg[1024] for an error message.
At the moment the size only needs to be 'big enough' but if the compiler
zeros it then there are performance issues and oversize buffers make
a difference.
At which point you start making the arrays 'just big enough' and then
fall foul of truncations and overruns because the calculation was wrong.

Definitely double edged.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)