Eric Lee / smarc-fsl-linux-kernel

14 Jan, 2020

1 commit

  • c576eddf1   drivers/misc: sram-exec: have the callers of set_memory_*() check the return value ... Browse Code »

    Right now several architectures allow their set_memory_*() family of
    functions to fail, but callers may not be checking the return values.
    If set_memory_*() returns with an error, call-site assumptions may be
    infact wrong to assume that it would either succeed or not succeed at
    all. Ideally, the failure of set_memory_*() should be passed up the call
    stack, and callers should examine the failure and deal with it.

    Need to fix the callers and add the __must_check attribute. They also
    may not provide any level of atomicity, in the sense that the memory
    protections may be left incomplete on failure. This issue likely has a
    few steps on effects architectures:
    1) Have all callers of set_memory_*() helpers check the return value.
    2) Add __must_check to all set_memory_*() helpers so that new uses do
    not ignore the return value.
    3) Add atomicity to the calls so that the memory protections aren't
    left in a partial state.

    This series is part of step 1. Make sram driver check the return value
    of set_memory_*().

    Signed-off-by: Tianlin Li
    Reviewed-by: Kees Cook
    Link: https://lore.kernel.org/r/20191217194528.16461-1-tli@digitalocean.com
    Signed-off-by: Greg Kroah-Hartman

    Tianlin Li
     

05 Dec, 2019

1 commit

  • 964975ac6   lib/genalloc.c: rename addr_in_gen_pool to gen_pool_has_addr ... Browse Code »

    Follow the kernel conventions, rename addr_in_gen_pool to
    gen_pool_has_addr.

    [sjhuang@iluvatar.ai: fix Documentation/ too]
    Link: http://lkml.kernel.org/r/20181229015914.5573-1-sjhuang@iluvatar.ai
    Link: http://lkml.kernel.org/r/20181228083950.20398-1-sjhuang@iluvatar.ai
    Signed-off-by: Huang Shijie
    Reviewed-by: Andrew Morton
    Cc: Russell King
    Cc: Arnd Bergmann
    Cc: Greg Kroah-Hartman
    Cc: Christoph Hellwig
    Cc: Marek Szyprowski
    Cc: Robin Murphy
    Cc: Stephen Rothwell
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Huang Shijie
     

18 May, 2017

1 commit

  • 34cfb106d   misc: sram-exec: Use aligned fncpy instead of memcpy ... Browse Code »

    Currently the sram-exec functionality, which allows allocation of
    executable memory and provides an API to move code to it, is only
    selected in configs for the ARM architecture. Based on commit
    5756e9dd0de6 ("ARM: 6640/1: Thumb-2: Symbol manipulation macros for
    function body copying") simply copying a C function pointer address
    using memcpy without consideration of alignment and Thumb is unsafe on
    ARM platforms.

    The aforementioned patch introduces the fncpy macro which is a safe way
    to copy executable code on ARM platforms, so let's make use of that here
    rather than the unsafe plain memcpy that was previously used by
    sram_exec_copy. Now sram_exec_copy will move the code to "dst" and
    return an address that is guaranteed to be safely callable.

    In the future, architectures hoping to make use of the sram-exec
    functionality must define an fncpy macro just as ARM has done to
    guarantee or check for safe copying to executable memory before allowing
    the arch to select CONFIG_SRAM_EXEC.

    Acked-by: Tony Lindgren
    Acked-by: Russell King
    Reviewed-by: Alexandre Belloni
    Signed-off-by: Dave Gerlach
    Signed-off-by: Greg Kroah-Hartman

    Dave Gerlach
     

09 May, 2017

1 commit

25 Jan, 2017

1 commit

  • 728bbe75c   misc: sram: Introduce support code for protect-exec sram type ... Browse Code »

    Some platforms, like many ARM SoCs, require the ability to run code from
    on-chip memory like SRAM for tasks like reconfiguring the SDRAM
    controller or entering low-power sleep modes. In order to do this we
    must be able to allocate memory that the code can be copied to but then
    change the mapping to be read-only and executable so that no memory is
    both writable and executable at the same time to avoid opening any
    unneccesary security holes.

    By using the existing "pool" partition type that the SRAM driver allows
    we can create a memory space that will already be exposed by the
    genalloc framework to allow for allocating memory but we must extend
    this to meet the executable requirements. By making use of various
    set_memory_* APIs we can change the attributes of pages to make them
    writable for code upload but then read-only and executable when we want
    to actually run code. Because SRAM is a shared resource we need a
    centralized manager of these set memory calls. Because the SRAM driver
    itself is responsible for allocating the memory we can introduce a
    sram_copy_exec API for the driver that works like memcpy but also
    manages the page attributes and locking to allow multiple users of the
    same SRAM space to all copy their code over independent of other each
    before starting execution.

    It is maintained in a separate file from the core SRAM driver to allow
    it to be selectively built depending on whether or not a platform has
    the appropriate set_memory_* APIs. A future patch will integrate it with
    the core SRAM driver.

    Signed-off-by: Dave Gerlach
    Acked-by: Tony Lindgren
    Signed-off-by: Greg Kroah-Hartman

    Dave Gerlach