Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Wed, 27 Nov 2019 11:01:15 -0800
From: Kees Cook <>
To: "Shiyunming (Seth, RTOS)" <>
Cc: "" <>,
	"lizi (D)" <>, "Sunke (SK)" <>,
	Jiangyangyang <>,
	Linzichang <>,, Arnd Bergmann <>,
	"Gustavo A. R. Silva" <>
Subject: Re: Questions about "security functions" and "suppression of
 compilation alarms".

On Wed, Nov 27, 2019 at 01:11:50PM +0000, Shiyunming (Seth, RTOS) wrote:
> During the use of Linux, I found lots of C standard functions such
> as memcpy and strcpy etc. These functions did not check the size of
> the target buffer and easily introduced the security vulnerability of
> buffer overflow.

See CONFIG_FORTIFY_SOURCE (which enables such bounds checking):
and the plans for improvement:

> And some compilation options are enabled to suppress compilation alarms,
> for example (Wno-format-security Wno-pointer-sign Wno-frame-address
> Wno-maybe-uninitialized Wno-format-overflow Wno-int-in-bool-context),
> which may bring potential security problems.

Each of these needs to be handled on a case-by-case basis. Kernel builds
are expected to build without warnings, so before a new compiler flag
can be added to the global build, all the instances need to be
addressed. (Flags are regularly turned off because they are enabled by
default in newer compiler versions but this causes too many warnings.)
See the "W=1", "W=2", etc build options for enabling these:

Once all instances of a warning are eliminated, these warnings can be
moved to the top-level Makefile. Arnd Bergmann does a lot of this work
and might be able to speak more coherently about this. :) For example,
here is enabling of -Wmaybe-uninitialized back in the v4.10 kernel:

Speaking specifically to your list:

  This has tons of false positives, and likely requires fixing the

  Lots of things in the kernel pass pointers around in weird ways. This
  is disabled to allow normal operation (which, combined with
  -fwrapv-pointer and -fwrapv via -fno-strict-overflow) means signed
  things and pointers behave without "undefined behavior". A lot of work
  would be needed all over the kernel to enable this warning (and part
  of that would be incrementally removing unexpected overflows of both
  unsigned and signed arithmetic).

  __builtin_frame_address() gets used in "safe" places on the
  architectures where the limitations are understood, so adding this
  warning doesn't gain anything because it's already rare and gets
  some scrutiny.

  And linked above, this is enabled by default since v4.10.

  for details. Eliminating these warnings (there were 1500) needs to
  happen before they can be turned back on. Any help here is very

  where it was enabled again in v5.2 after Arnd cleaned up the associated

> In response to these circumstances, my question is:
> (1) Does the kernel community think that using these functions and
> compiling alarm suppression have security problems?

Generally speaking, yes, of course, if we have tools that provide the
code base with better security (or more specifically, a reduction in all
bugs, not just those that may have security implications), we want to
use them. However, such things need to have a false positive rate that is
close to zero. If it has a high false positive rate, then there needs to
be a strong indication that the true positives are very serious problems
and some mechanism can be implemented to silence the false positives.

>     If it is considered as a problem, will the developer be promoted
> to fix it?

Warnings seen from newly introduced code get fixed very quickly, yes.
Problems that were already existing and are surfaced by new warnings
tend to get less direct attention by maintainers since it creates a
large amount of work where it is hard to measure the benefit. However,
people contributing changes in these areas tend to be very well received.
For example, Gustavo A. R. Silva did a huge amount of work to enable

>     If it is not considered as a problem, what is the reason?

Hopefully I've explained the nuances in this email. :)

> (2) The C11 specification contains security enhancement functions. What
> is the policy of the community about them? Is there any plan to use
> these functions?

Which do you mean specifically? Generally speaking, the community is
open to anything that can be reasonably maintained. :)

Are there any features you've tried to enable and you'd be interested in
submitting patches to fix?

Thanks for the questions!

Kees Cook

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.