public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
From: David Laight <David.Laight@ACULAB.COM>
To: 'Kees Cook' <keescook@chromium.org>, Robin Murphy <robin.murphy@arm.com>
Cc: Ard Biesheuvel <ardb@kernel.org>,
	Victor Erminpour <victor.erminpour@oracle.com>,
	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	Hanjun Guo <guohanjun@huawei.com>,
	Sudeep Holla <sudeep.holla@arm.com>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Len Brown <lenb@kernel.org>,
	"ACPI Devel Maling List" <linux-acpi@vger.kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"trivial@kernel.org" <trivial@kernel.org>
Subject: RE: [PATCH v2] ACPI/IORT: Fix GCC 12 warning
Date: Sun, 13 Feb 2022 03:33:44 +0000	[thread overview]
Message-ID: <f11f91706c704a72b593a183f33ff456@AcuMS.aculab.com> (raw)
In-Reply-To: <202202111623.A7881CC@keescook>

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)


  parent reply	other threads:[~2022-02-13  3:33 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-10 18:47 [PATCH v2] ACPI/IORT: Fix GCC 12 warning Victor Erminpour
2022-02-10 19:41 ` Ard Biesheuvel
2022-02-10 23:47   ` Kees Cook
2022-02-11 10:34     ` Robin Murphy
2022-02-11 11:43       ` Ard Biesheuvel
2022-02-11 12:15         ` Robin Murphy
2022-02-11 17:08           ` Ard Biesheuvel
2022-02-11 17:11             ` Robin Murphy
2022-02-12  0:37       ` Kees Cook
2022-02-12  4:50         ` Joe Perches
2022-02-13  3:33         ` David Laight [this message]
2022-02-13  2:20     ` David Laight

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f11f91706c704a72b593a183f33ff456@AcuMS.aculab.com \
    --to=david.laight@aculab.com \
    --cc=ardb@kernel.org \
    --cc=guohanjun@huawei.com \
    --cc=keescook@chromium.org \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=rafael@kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=sudeep.holla@arm.com \
    --cc=trivial@kernel.org \
    --cc=victor.erminpour@oracle.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox