25 Mar, 2014

1 commit


17 Mar, 2014

1 commit


10 Mar, 2014

1 commit


03 Mar, 2014

1 commit


26 Feb, 2014

2 commits

  • According to Documentation/Changes, make 3.80 is still being supported
    for building the kernel, hence make files must not make (unconditional)
    use of features introduced only in newer versions. Commit 8779657d29c0
    ("stackprotector: Introduce CONFIG_CC_STACKPROTECTOR_STRONG") however
    introduced an "else ifdef" construct which make 3.80 doesn't understand.

    Also correct a warning message still referencing the old config option
    name.

    Apart from that I question the use of "ifdef" here (but it was used that
    way already prior to said commit): ifeq (,y) would seem more to the
    point.

    Signed-off-by: Jan Beulich
    Acked-by: Kees Cook
    Cc: Ingo Molnar
    Cc: Michal Marek
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jan Beulich
     
  • An extra parenthesis typo introduced in 19952a92037e ("stackprotector:
    Unify the HAVE_CC_STACKPROTECTOR logic between architectures") is
    causing the following error when CONFIG_CC_STACKPROTECTOR_REGULAR is
    enabled:

    Makefile:608: Cannot use CONFIG_CC_STACKPROTECTOR: -fstack-protector not supported by compiler
    Makefile:608: *** missing separator. Stop.

    Signed-off-by: Fathi Boudra
    Acked-by: Kees Cook
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Fathi Boudra
     

24 Feb, 2014

1 commit


17 Feb, 2014

1 commit


10 Feb, 2014

1 commit


03 Feb, 2014

1 commit


31 Jan, 2014

2 commits

  • Pull __TIME__/__DATE__ removal from Michal Marek:
    "This series by Josh finishes the removal of __DATE__ and __TIME__ from
    the kernel. The last patch adds -Werror=date-time to KBUILD_CFLAGS to
    stop these from reappearing.

    Part of the series went through Greg's trees during this merge window,
    which is why this pull request is not based on v3.13-rc1"

    * 'drop-time' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild:
    Makefile: Build with -Werror=date-time if the compiler supports it
    x86: math-emu: Drop already-disabled print of build date
    net: wireless: brcm80211: Drop debug version with build date/time
    mtd: denali: Drop print of build date/time

    Linus Torvalds
     
  • Pull kbuild changes from Michal Marek:
    - fix make -s detection with make-4.0
    - fix for scripts/setlocalversion when the kernel repository is a
    submodule
    - do not hardcode ';' in macros that expand to assembler code, as some
    architectures' assemblers use a different character for newline
    - Fix passing --gdwarf-2 to the assembler

    * 'kbuild' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild:
    frv: Remove redundant debugging info flag
    mn10300: Remove redundant debugging info flag
    kbuild: Fix debugging info generation for .S files
    arch: use ASM_NL instead of ';' for assembler new line character in the macro
    kbuild: Fix silent builds with make-4
    Fix detectition of kernel git repository in setlocalversion script [take #2]

    Linus Torvalds
     

28 Jan, 2014

2 commits

  • GCC 4.9 and newer have a new warning -Wdate-time, which warns on any use
    of __DATE__, __TIME__, or __TIMESTAMP__, which would make the build
    non-deterministic. Now that the kernel does not use any of those
    macros, turn on -Werror=date-time if available, to keep it that way.

    The kernel already (optionally) records this information at build time
    in a single place; other kernel code should not duplicate that.

    Signed-off-by: Josh Triplett
    Signed-off-by: Michal Marek

    Josh Triplett
     
  • Change the debuging info generation flag in KBUILD_AFLAGS from '-gdwarf-2' to
    '-Wa,--gdwarf-2'. This will properly generate the debugging info for .S files
    when CONFIG_DEBUG_INFO=y.

    It seems current gcc does not pass a '--gdwarf-2' option on to the assembler
    when '-gdwarf-2' is on its command line (note the differece in the gcc and as
    flags). This change provides the correct assembler flag to gcc, and so does
    not rely on gcc to emit a flag for the assembler.

    Signed-off-by: Geoff Levand for Huawei, Linaro
    Signed-off-by: Michal Marek

    Geoff Levand
     

21 Jan, 2014

1 commit

  • …ux/kernel/git/tip/tip

    Pull strong stackprotector support from Ingo Molnar:
    "This tree adds a CONFIG_CC_STACKPROTECTOR_STRONG=y, a new, stronger
    stack canary checking method supported by the newest GCC versions (4.9
    and later).

    Here's the 'intensity comparison' between the various protection
    modes:

    - defconfig
    11430641 kernel text size
    36110 function bodies

    - defconfig + CONFIG_CC_STACKPROTECTOR_REGULAR
    11468490 kernel text size (+0.33%)
    1015 of 36110 functions are stack-protected (2.81%)

    - defconfig + CONFIG_CC_STACKPROTECTOR_STRONG via this patch
    11692790 kernel text size (+2.24%)
    7401 of 36110 functions are stack-protected (20.5%)

    the strong model comes with non-trivial costs, which is why we
    preserved the 'regular' and 'none' models as well"

    * 'core-stackprotector-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
    stackprotector: Introduce CONFIG_CC_STACKPROTECTOR_STRONG
    stackprotector: Unify the HAVE_CC_STACKPROTECTOR logic between architectures

    Linus Torvalds
     

20 Jan, 2014

1 commit


12 Jan, 2014

1 commit


06 Jan, 2014

1 commit

  • make-4 changed the way/order it presents the command line options
    into MAKEFLAGS

    In make-3.8x, '-s' would always be first into a group of options
    with the '-'/hyphen removed

    $ make -p -s 2>/dev/null | grep ^MAKEFLAGS
    MAKEFLAGS = sp

    In make-4, '-s' seems to always be last into a group of options
    with the '-'/hyphen removed

    $ make -s -p 2>/dev/null | grep ^MAKEFLAGS
    MAKEFLAGS = ps

    Signed-off-by: Emil Medve
    Signed-off-by: Michal Marek

    Emil Medve
     

05 Jan, 2014

1 commit


30 Dec, 2013

1 commit


23 Dec, 2013

1 commit


21 Dec, 2013

1 commit

  • Commit 1bf49dd4be0b ("./Makefile: export initial ramdisk compression
    config option") started setting the INITRD_COMPRESS environment variable
    depending on which decompression models the kernel had available.

    That is completely broken.

    For example, we by default have CONFIG_RD_LZ4 enabled, and are able to
    decompress such an initrd, but the user tools to *create* such an initrd
    may not be availble. So trying to tell dracut to generate an
    lz4-compressed image just because we can decode such an image is
    completely inappropriate.

    Cc: J P
    Cc: Andrew Morton
    Cc: Jan Beulich
    Signed-off-by: Linus Torvalds

    Linus Torvalds
     

20 Dec, 2013

2 commits

  • This changes the stack protector config option into a choice of
    "None", "Regular", and "Strong":

    CONFIG_CC_STACKPROTECTOR_NONE
    CONFIG_CC_STACKPROTECTOR_REGULAR
    CONFIG_CC_STACKPROTECTOR_STRONG

    "Regular" means the old CONFIG_CC_STACKPROTECTOR=y option.

    "Strong" is a new mode introduced by this patch. With "Strong" the
    kernel is built with -fstack-protector-strong (available in
    gcc 4.9 and later). This option increases the coverage of the stack
    protector without the heavy performance hit of -fstack-protector-all.

    For reference, the stack protector options available in gcc are:

    -fstack-protector-all:
    Adds the stack-canary saving prefix and stack-canary checking
    suffix to _all_ function entry and exit. Results in substantial
    use of stack space for saving the canary for deep stack users
    (e.g. historically xfs), and measurable (though shockingly still
    low) performance hit due to all the saving/checking. Really not
    suitable for sane systems, and was entirely removed as an option
    from the kernel many years ago.

    -fstack-protector:
    Adds the canary save/check to functions that define an 8
    (--param=ssp-buffer-size=N, N=8 by default) or more byte local
    char array. Traditionally, stack overflows happened with
    string-based manipulations, so this was a way to find those
    functions. Very few total functions actually get the canary; no
    measurable performance or size overhead.

    -fstack-protector-strong
    Adds the canary for a wider set of functions, since it's not
    just those with strings that have ultimately been vulnerable to
    stack-busting. With this superset, more functions end up with a
    canary, but it still remains small compared to all functions
    with only a small change in performance. Based on the original
    design document, a function gets the canary when it contains any
    of:

    - local variable's address used as part of the right hand side
    of an assignment or function argument
    - local variable is an array (or union containing an array),
    regardless of array type or length
    - uses register local variables

    https://docs.google.com/a/google.com/document/d/1xXBH6rRZue4f296vGt9YQcuLVQHeE516stHwt8M9xyU

    Find below a comparison of "size" and "objdump" output when built with
    gcc-4.9 in three configurations:

    - defconfig
    11430641 kernel text size
    36110 function bodies

    - defconfig + CONFIG_CC_STACKPROTECTOR_REGULAR
    11468490 kernel text size (+0.33%)
    1015 of 36110 functions are stack-protected (2.81%)

    - defconfig + CONFIG_CC_STACKPROTECTOR_STRONG via this patch
    11692790 kernel text size (+2.24%)
    7401 of 36110 functions are stack-protected (20.5%)

    With -strong, ARM's compressed boot code now triggers stack
    protection, so a static guard was added. Since this is only used
    during decompression and was never used before, the exposure
    here is very small. Once it switches to the full kernel, the
    stack guard is back to normal.

    Chrome OS has been using -fstack-protector-strong for its kernel
    builds for the last 8 months with no problems.

    Signed-off-by: Kees Cook
    Cc: Arjan van de Ven
    Cc: Michal Marek
    Cc: Russell King
    Cc: Ralf Baechle
    Cc: Paul Mundt
    Cc: James Hogan
    Cc: Stephen Rothwell
    Cc: Shawn Guo
    Cc: Linus Torvalds
    Cc: Andrew Morton
    Cc: Peter Zijlstra
    Cc: linux-arm-kernel@lists.infradead.org
    Cc: linux-mips@linux-mips.org
    Cc: linux-arch@vger.kernel.org
    Link: http://lkml.kernel.org/r/1387481759-14535-3-git-send-email-keescook@chromium.org
    [ Improved the changelog and descriptions some more. ]
    Signed-off-by: Ingo Molnar

    Kees Cook
     
  • Instead of duplicating the CC_STACKPROTECTOR Kconfig and
    Makefile logic in each architecture, switch to using
    HAVE_CC_STACKPROTECTOR and keep everything in one place. This
    retains the x86-specific bug verification scripts.

    Signed-off-by: Kees Cook
    Cc: Arjan van de Ven
    Cc: Michal Marek
    Cc: Russell King
    Cc: Ralf Baechle
    Cc: Paul Mundt
    Cc: James Hogan
    Cc: Stephen Rothwell
    Cc: Shawn Guo
    Cc: Linus Torvalds
    Cc: Andrew Morton
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Cc: linux-arm-kernel@lists.infradead.org
    Cc: linux-mips@linux-mips.org
    Cc: linux-arch@vger.kernel.org
    Link: http://lkml.kernel.org/r/1387481759-14535-2-git-send-email-keescook@chromium.org
    Signed-off-by: Ingo Molnar

    Kees Cook
     

19 Dec, 2013

1 commit

  • According to Documentation/Changes, make 3.80 is still being supported
    for building the kernel, hence make files must not make (unconditional)
    use of features introduced only in newer versions.

    Commit 1bf49dd4be0b ("./Makefile: export initial ramdisk compression
    config option") however introduced "else ifeq" constructs which make
    3.80 doesn't understand. Replace the logic there with more conventional
    (in the kernel build infrastructure) list constructs (except that the
    list here is intentionally limited to exactly one element).

    Signed-off-by: Jan Beulich
    Cc: P J P
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jan Beulich
     

16 Dec, 2013

1 commit


07 Dec, 2013

1 commit


30 Nov, 2013

1 commit


23 Nov, 2013

1 commit


16 Nov, 2013

1 commit

  • Pull kbuild changes from Michal Marek:
    - LTO fixes, but the kallsyms part had to be reverted
    - Pass -Werror=implicit-int and -Werror=strict-prototypes to the
    compiler by default
    - snprintf fix in modpost
    - remove GREP_OPTIONS from the environment to be immune against exotic
    grep option settings

    * 'kbuild' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild:
    kallsyms: Revert back to 128 max symbol length
    Kbuild: Ignore GREP_OPTIONS env variable
    scripts: kallsyms: Use %zu to print 'size_t'
    scripts/bloat-o-meter: use .startswith rather than fragile slicing
    scripts/bloat-o-meter: ignore changes in the size of linux_banner
    kbuild: replace unbounded sprintf call in modpost
    kbuild, bloat-o-meter: fix static detection
    Kbuild: Handle longer symbols in kallsyms.c
    kbuild: Increase kallsyms max symbol length
    Makefile: enable -Werror=implicit-int and -Werror=strict-prototypes by default

    Linus Torvalds
     

13 Nov, 2013

1 commit

  • Make menuconfig allows one to choose compression format of an initial
    ramdisk image. But this choice does not result in duly compressed ramdisk
    image. Because - $ make install - does not pass on the selected
    compression choice to the dracut(8) tool, which creates the initramfs
    file. dracut(8) generates the image with the default compression, ie.
    gzip(1).

    This patch exports the selected compression option to a sub-shell
    environment, so that it could be used by dracut(8) tool to generate
    appropriately compressed initramfs images.

    There isn't a straightforward way to pass on options to dracut(8) via
    positional parameters. Because it is indirectly invoked at the end of a $
    make install sequence.

    # make install
    -> arch/$arch/boot/Makefile
    -> arch/$arch/boot/install.sh
    -> /sbing/installkernel ...
    -> /sbin/new-kernel-pkg ...
    -> /sbin/dracut ...

    Signed-off-by: P J P
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    P J P
     

12 Nov, 2013

1 commit

  • When building the kernel in a shell which defines GREP_OPTIONS so that
    grep behavior is modified, we can break the generation of the syscalls
    table like so:

    __SYSCALL_COMMON(^[[01;31m^[[K0^[[m^[[K, sys_read, sys_read)
    __SYSCALL_COMMON(^[[01;31m^[[K1^[[m^[[K, sys_write, sys_write)
    __SYSCALL_COMMON(^[[01;31m^[[K1^[[m^[[K0, sys_mprotect, sys_mprotect) ...

    This is just the initial breakage, later we barf when generating
    modules.

    In this case, GREP_OPTIONS contains "--color=always" which adds the shell
    colors markup and completely fudges the headers under ...generated/asm/.

    Fix that by unexporting the GREP_OPTIONS variable for the whole kernel
    build as we tend to use grep at a bunch of places.

    Signed-off-by: Borislav Petkov
    Signed-off-by: Michal Marek

    Borislav Petkov
     

04 Nov, 2013

1 commit


28 Oct, 2013

1 commit


23 Oct, 2013

1 commit

  • The common error found in forward-ported/backported patches is missing
    headers. One recent example (files and function names are mangled):

    void foo(){}
    EXPORT_SYMBOL(foo);

    gave only warning

    foo.c:12345678:5: warning: function declaration isn't a prototype [-Wstrict-prototypes]
    void foo(){}
    ^

    foo.c:12345679:5: warning: data definition has no type or storage class [enabled by default]
    EXPORT_SYMBOL(foo);
    foo.c:12345679:5: warning: type defaults to 'int' in declaration of 'EXORT_SYMBOL' [-Werror=implicit-int]

    Now it's a fatal error. Tested on x86_64 allyesconfig.

    [akpm@linux-foundation.org: fix typos in comments]
    Signed-off-by: Sergei Trofimovich
    Cc: Geert Uytterhoeven
    Signed-off-by: Andrew Morton
    Signed-off-by: Michal Marek

    Sergei Trofimovich
     

20 Oct, 2013

1 commit


14 Oct, 2013

1 commit


07 Oct, 2013

1 commit


30 Sep, 2013

1 commit


24 Sep, 2013

1 commit