Skip to content
Snippets Groups Projects
Select Git revision
0 results
Search by author
  • Any Author
0 authors
  1. Feb 10, 2021
    • Josh Poimboeuf's avatar
      x86/build: Disable CET instrumentation in the kernel · 7175b118
      Josh Poimboeuf authored 
      
commit 20bf2b37 upstream.

With retpolines disabled, some configurations of GCC, and specifically
the GCC versions 9 and 10 in Ubuntu will add Intel CET instrumentation
to the kernel by default. That breaks certain tracing scenarios by
adding a superfluous ENDBR64 instruction before the fentry call, for
functions which can be called indirectly.

CET instrumentation isn't currently necessary in the kernel, as CET is
only supported in user space. Disable it unconditionally and move it
into the x86's Makefile as CET/CFI... enablement should be a per-arch
decision anyway.

 [ bp: Massage and extend commit message. ]

Fixes: 29be86d7 ("kbuild: add -fcf-protection=none when using retpoline flags")
Reported-by: default avatarNikolay Borisov <nborisov@suse.com>
Signed-off-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
Reviewed-by: default avatarNikolay Borisov <nborisov@suse.com>
Tested-by: default avatarNikolay Borisov <nborisov@suse.com>
Cc: <stable@vger.kernel.org>
Cc: Seth Forshee <seth.forshee@canonical.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Link: https://lkml.kernel.org/r/20210128215219.6kct3h2eiustncws@treble


Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7175b118
    • Sasha Levin's avatar
      stable: clamp SUBLEVEL in 4.4 and 4.9 · 42efb098
      Sasha Levin authored 
      
Right now SUBLEVEL is overflowing, and some userspace may start treating
4.9.256 as 4.10. While out of tree modules have different ways of
  extracting the version number (and we're generally ok with breaking
them), we do care about breaking userspace and it would appear that this
overflow might do just that.

Our rules around userspace ABI in the stable kernel are pretty simple:
we don't break it. Thus, while userspace may be checking major/minor, it
shouldn't be doing anything with sublevel.

This patch applies a big band-aid to the 4.9 and 4.4 kernels in the form
of clamping their sublevel to 255.

The clamp is done for the purpose of LINUX_VERSION_CODE only, and
extracting the version number from the Makefile or "make kernelversion"
will continue to work as intended.

We might need to do it later in newer trees, but maybe we'll have a
better solution by then, so I'm ignoring that problem for now.

Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      42efb098
  3. Feb 05, 2021
  5. Feb 03, 2021
  7. Jan 30, 2021
  9. Jan 23, 2021
  11. Jan 17, 2021
  13. Jan 12, 2021
  15. Jan 09, 2021
  17. Dec 29, 2020
  19. Dec 11, 2020
  21. Dec 02, 2020
  23. Nov 24, 2020
  25. Nov 22, 2020
  27. Nov 18, 2020
  29. Nov 10, 2020
  31. Oct 29, 2020
  33. Oct 17, 2020
  35. Oct 14, 2020
  37. Oct 01, 2020
  39. Sep 23, 2020
  41. Sep 12, 2020
  43. Sep 03, 2020
  45. Aug 26, 2020
  47. Aug 21, 2020
  49. Jul 31, 2020
  51. Jul 22, 2020
  53. Jul 09, 2020
  55. Jun 30, 2020
  57. Jun 20, 2020
  59. Jun 11, 2020
  61. Jun 03, 2020
  63. May 27, 2020
  65. May 20, 2020
    • Greg Kroah-Hartman's avatar
      Linux 4.9.224 · e4ebe4fa
      Greg Kroah-Hartman authored
      v4.9.224
      e4ebe4fa
    • Sergei Trofimovich's avatar
      Makefile: disallow data races on gcc-10 as well · 3bead443
      Sergei Trofimovich authored 
      commit b1112139 upstream.

gcc-10 will rename --param=allow-store-data-races=0
to -fno-allow-store-data-races.

The flag change happened at https://gcc.gnu.org/PR92046

.

Signed-off-by: default avatarSergei Trofimovich <slyfox@gentoo.org>
Acked-by: default avatarJiri Kosina <jkosina@suse.cz>
Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
Cc: Thomas Backlund <tmb@mageia.org>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3bead443
    • Linus Torvalds's avatar
      gcc-10: disable 'restrict' warning for now · 9799d957
      Linus Torvalds authored 
      
commit adc71920 upstream.

gcc-10 now warns about passing aliasing pointers to functions that take
restricted pointers.

That's actually a great warning, and if we ever start using 'restrict'
in the kernel, it might be quite useful.  But right now we don't, and it
turns out that the only thing this warns about is an idiom where we have
declared a few functions to be "printf-like" (which seems to make gcc
pick up the restricted pointer thing), and then we print to the same
buffer that we also use as an input.

And people do that as an odd concatenation pattern, with code like this:

    #define sysfs_show_gen_prop(buffer, fmt, ...) \
        snprintf(buffer, PAGE_SIZE, "%s"fmt, buffer, __VA_ARGS__)

where we have 'buffer' as both the destination of the final result, and
as the initial argument.

Yes, it's a bit questionable.  And outside of the kernel, people do have
standard declarations like

    int snprintf( char *restrict buffer, size_t bufsz,
                  const char *restrict format, ... );

where that output buffer is marked as a restrict pointer that cannot
alias with any other arguments.

But in the context of the kernel, that 'use snprintf() to concatenate to
the end result' does work, and the pattern shows up in multiple places.
And we have not marked our own version of snprintf() as taking restrict
pointers, so the warning is incorrect for now, and gcc picks it up on
its own.

If we do start using 'restrict' in the kernel (and it might be a good
idea if people find places where it matters), we'll need to figure out
how to avoid this issue for snprintf and friends.  But in the meantime,
this warning is not useful.

Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9799d957