14 Jun, 2018

1 commit

  • The changes to automatically test for working stack protector compiler
    support in the Kconfig files removed the special STACKPROTECTOR_AUTO
    option that picked the strongest stack protector that the compiler
    supported.

    That was all a nice cleanup - it makes no sense to have the AUTO case
    now that the Kconfig phase can just determine the compiler support
    directly.

    HOWEVER.

    It also meant that doing "make oldconfig" would now _disable_ the strong
    stackprotector if you had AUTO enabled, because in a legacy config file,
    the sane stack protector configuration would look like

    CONFIG_HAVE_CC_STACKPROTECTOR=y
    # CONFIG_CC_STACKPROTECTOR_NONE is not set
    # CONFIG_CC_STACKPROTECTOR_REGULAR is not set
    # CONFIG_CC_STACKPROTECTOR_STRONG is not set
    CONFIG_CC_STACKPROTECTOR_AUTO=y

    and when you ran this through "make oldconfig" with the Kbuild changes,
    it would ask you about the regular CONFIG_CC_STACKPROTECTOR (that had
    been renamed from CONFIG_CC_STACKPROTECTOR_REGULAR to just
    CONFIG_CC_STACKPROTECTOR), but it would think that the STRONG version
    used to be disabled (because it was really enabled by AUTO), and would
    disable it in the new config, resulting in:

    CONFIG_HAVE_CC_STACKPROTECTOR=y
    CONFIG_CC_HAS_STACKPROTECTOR_NONE=y
    CONFIG_CC_STACKPROTECTOR=y
    # CONFIG_CC_STACKPROTECTOR_STRONG is not set
    CONFIG_CC_HAS_SANE_STACKPROTECTOR=y

    That's dangerously subtle - people could suddenly find themselves with
    the weaker stack protector setup without even realizing.

    The solution here is to just rename not just the old RECULAR stack
    protector option, but also the strong one. This does that by just
    removing the CC_ prefix entirely for the user choices, because it really
    is not about the compiler support (the compiler support now instead
    automatially impacts _visibility_ of the options to users).

    This results in "make oldconfig" actually asking the user for their
    choice, so that we don't have any silent subtle security model changes.
    The end result would generally look like this:

    CONFIG_HAVE_CC_STACKPROTECTOR=y
    CONFIG_CC_HAS_STACKPROTECTOR_NONE=y
    CONFIG_STACKPROTECTOR=y
    CONFIG_STACKPROTECTOR_STRONG=y
    CONFIG_CC_HAS_SANE_STACKPROTECTOR=y

    where the "CC_" versions really are about internal compiler
    infrastructure, not the user selections.

    Acked-by: Masahiro Yamada
    Signed-off-by: Linus Torvalds

    Linus Torvalds
     

09 Jun, 2017

3 commits

  • Enable CPU domain PAN to ensure that normal kernel accesses are
    unable to access userspace addresses.

    Reviewed-at: https://android-review.googlesource.com/#/c/334035/

    Signed-off-by: Sami Tolvanen
    [AmitP: cherry-picked this change from Android common kernel, updated
    the commit message and re-placed the CONFIG_STRICT_KERNEL_RWX
    config in sorted order]
    Signed-off-by: Amit Pundir
    Signed-off-by: Greg Kroah-Hartman

    Sami Tolvanen
     
  • Enable PAN emulation using TTBR0_EL1 switching.

    Reviewed-at: https://android-review.googlesource.com/#/c/325997/

    Signed-off-by: Sami Tolvanen
    [AmitP: cherry-picked this change from Android common kernel
    and updated the commit message]
    Signed-off-by: Amit Pundir
    Signed-off-by: Greg Kroah-Hartman

    Sami Tolvanen
     
  • If compiler has stack protector support, set
    CONFIG_CC_STACKPROTECTOR_STRONG.

    Reviewed-at: https://android-review.googlesource.com/#/c/238388/

    Signed-off-by: Jeff Vander Stoep
    [AmitP: cherry-picked this change from Android common kernel]
    Signed-off-by: Amit Pundir
    Signed-off-by: Greg Kroah-Hartman

    Jeff Vander Stoep
     

28 Feb, 2017

1 commit

  • The aio interface adds substantial attack surface for a feature that's
    not being exposed by Android at all. It's unlikely that anyone is using
    the kernel feature directly either. This feature is rarely used even on
    servers. The glibc POSIX aio calls really use thread pools. The lack
    of widespread usage also means this is relatively poorly audited/tested.

    The kernel's aio rarely provides performance benefits over using a
    thread pool and is quite incomplete in terms of system call coverage
    along with having edge cases where blocking can occur. Part of the
    performance issue is the fact that it only supports direct io, not
    buffered io. The existing API is considered fundamentally flawed and
    it's unlikely it will be expanded, but rather replaced:

    https://marc.info/?l=linux-aio&m=145255815216051&w=2

    Since ext4 encryption means no direct io support, kernel aio isn't even
    going to work properly on Android devices using file-based encryption.

    Reviewed-at: https://android-review.googlesource.com/#/c/292158/

    Link: http://lkml.kernel.org/r/1481113148-29204-1-git-send-email-amit.pundir@linaro.org
    Signed-off-by: Daniel Micay
    Signed-off-by: Amit Pundir
    Cc: Rob Herring
    Cc: John Stultz
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Daniel Micay
     

08 Feb, 2017

1 commit

  • Both of these options are poorly named. The features they provide are
    necessary for system security and should not be considered debug only.
    Change the names to CONFIG_STRICT_KERNEL_RWX and
    CONFIG_STRICT_MODULE_RWX to better describe what these options do.

    Signed-off-by: Laura Abbott
    Acked-by: Jessica Yu
    Signed-off-by: Kees Cook

    Laura Abbott
     

12 Oct, 2016

1 commit

  • CONFIG_MD is in recommended, but other dependent options like DM_CRYPT and
    DM_VERITY options are in base. The result is the options in base don't
    get enabled when applying both base and recommended fragments. Move all
    the options to recommended.

    Link: http://lkml.kernel.org/r/20160908185934.18098-1-robh@kernel.org
    Signed-off-by: Rob Herring
    Acked-by: John Stultz
    Cc: Amit Pundir
    Cc: Dmitry Shmidt
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Rob Herring
     

03 Aug, 2016

1 commit

  • Copy the config fragments from the AOSP common kernel android-4.4
    branch. It is becoming possible to run mainline kernels with Android,
    but the kernel defconfigs don't work as-is and debugging missing config
    options is a pain. Adding the config fragments into the kernel tree,
    makes configuring a mainline kernel as simple as:

    make ARCH=arm multi_v7_defconfig android-base.config android-recommended.config

    The following non-upstream config options were removed:

    CONFIG_NETFILTER_XT_MATCH_QTAGUID
    CONFIG_NETFILTER_XT_MATCH_QUOTA2
    CONFIG_NETFILTER_XT_MATCH_QUOTA2_LOG
    CONFIG_PPPOLAC
    CONFIG_PPPOPNS
    CONFIG_SECURITY_PERF_EVENTS_RESTRICT
    CONFIG_USB_CONFIGFS_F_MTP
    CONFIG_USB_CONFIGFS_F_PTP
    CONFIG_USB_CONFIGFS_F_ACC
    CONFIG_USB_CONFIGFS_F_AUDIO_SRC
    CONFIG_USB_CONFIGFS_UEVENT
    CONFIG_INPUT_KEYCHORD
    CONFIG_INPUT_KEYRESET

    Link: http://lkml.kernel.org/r/1466708235-28593-1-git-send-email-robh@kernel.org
    Signed-off-by: Rob Herring
    Cc: Amit Pundir
    Cc: John Stultz
    Cc: Dmitry Shmidt
    Cc: Rom Lemarchand
    Cc: Greg Kroah-Hartman
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Rob Herring