AuxXxilium/linux_dsm_epyc7002
1
0
Fork 0
mirror of https://github.com/AuxXxilium/linux_dsm_epyc7002.git synced 2024-11-25 04:30:52 +07:00
Code Issues Actions Packages Projects Releases Wiki Activity
2067391195
linux_dsm_epyc7002/drivers/misc/sram-exec.c

133 lines
3.8 KiB
C
Raw Normal View History

misc: sram: Introduce support code for protect-exec sram type 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 <d-gerlach@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-13 03:52:19 +07:00
/*
* SRAM protect-exec region helper functions
*
* Copyright (C) 2017 Texas Instruments Incorporated - http://www.ti.com/
* Dave Gerlach
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*
* This program is distributed "as is" WITHOUT ANY WARRANTY of any
* kind, whether express or implied; without even the implied warranty
* of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*/
#include <linux/device.h>
#include <linux/genalloc.h>
drivers/misc/sram-exec.c: use set_memory.h header set_memory_* functions have moved to set_memory.h. Switch to this explicitly. Link: http://lkml.kernel.org/r/1488920133-27229-15-git-send-email-labbott@redhat.com Signed-off-by: Laura Abbott <labbott@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-05-09 05:58:38 +07:00
#include <linux/mm.h>
misc: sram: Introduce support code for protect-exec sram type 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 <d-gerlach@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-13 03:52:19 +07:00
#include <linux/sram.h>
misc: sram-exec: Use aligned fncpy instead of memcpy 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 <tony@atomide.com> Acked-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Alexandre Belloni <alexandre.belloni@free-electrons.com> Signed-off-by: Dave Gerlach <d-gerlach@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-05-18 22:07:06 +07:00
#include <asm/fncpy.h>
drivers/misc/sram-exec.c: use set_memory.h header set_memory_* functions have moved to set_memory.h. Switch to this explicitly. Link: http://lkml.kernel.org/r/1488920133-27229-15-git-send-email-labbott@redhat.com Signed-off-by: Laura Abbott <labbott@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-05-09 05:58:38 +07:00
#include <asm/set_memory.h>
misc: sram: Introduce support code for protect-exec sram type 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 <d-gerlach@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-13 03:52:19 +07:00
#include "sram.h"
static DEFINE_MUTEX(exec_pool_list_mutex);
static LIST_HEAD(exec_pool_list);
int sram_check_protect_exec(struct sram_dev *sram, struct sram_reserve *block,
struct sram_partition *part)
{
unsigned long base = (unsigned long)part->base;
unsigned long end = base + block->size;
if (!PAGE_ALIGNED(base) || !PAGE_ALIGNED(end)) {
dev_err(sram->dev,
"SRAM pool marked with 'protect-exec' is not page aligned and will not be created.\n");
return -ENOMEM;
}
return 0;
}
int sram_add_protect_exec(struct sram_partition *part)
{
mutex_lock(&exec_pool_list_mutex);
list_add_tail(&part->list, &exec_pool_list);
mutex_unlock(&exec_pool_list_mutex);
return 0;
}
/**
* sram_exec_copy - copy data to a protected executable region of sram
*
* @pool: struct gen_pool retrieved that is part of this sram
* @dst: Destination address for the copy, that must be inside pool
* @src: Source address for the data to copy
* @size: Size of copy to perform, which starting from dst, must reside in pool
*
misc: sram-exec: Use aligned fncpy instead of memcpy 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 <tony@atomide.com> Acked-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Alexandre Belloni <alexandre.belloni@free-electrons.com> Signed-off-by: Dave Gerlach <d-gerlach@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-05-18 22:07:06 +07:00
* Return: Address for copied data that can safely be called through function
* pointer, or NULL if problem.
*
misc: sram: Introduce support code for protect-exec sram type 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 <d-gerlach@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-13 03:52:19 +07:00
* This helper function allows sram driver to act as central control location
* of 'protect-exec' pools which are normal sram pools but are always set
* read-only and executable except when copying data to them, at which point
* they are set to read-write non-executable, to make sure no memory is
* writeable and executable at the same time. This region must be page-aligned
* and is checked during probe, otherwise page attribute manipulation would
misc: sram-exec: Use aligned fncpy instead of memcpy 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 <tony@atomide.com> Acked-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Alexandre Belloni <alexandre.belloni@free-electrons.com> Signed-off-by: Dave Gerlach <d-gerlach@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-05-18 22:07:06 +07:00
* not be possible. Care must be taken to only call the returned address as
* dst address is not guaranteed to be safely callable.
*
* NOTE: This function uses the fncpy macro to move code to the executable
* region. Some architectures have strict requirements for relocating
* executable code, so fncpy is a macro that must be defined by any arch
* making use of this functionality that guarantees a safe copy of exec
* data and returns a safe address that can be called as a C function
* pointer.
misc: sram: Introduce support code for protect-exec sram type 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 <d-gerlach@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-13 03:52:19 +07:00
*/
misc: sram-exec: Use aligned fncpy instead of memcpy 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 <tony@atomide.com> Acked-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Alexandre Belloni <alexandre.belloni@free-electrons.com> Signed-off-by: Dave Gerlach <d-gerlach@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-05-18 22:07:06 +07:00
void *sram_exec_copy(struct gen_pool *pool, void *dst, void *src,
size_t size)
misc: sram: Introduce support code for protect-exec sram type 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 <d-gerlach@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-13 03:52:19 +07:00
{
struct sram_partition *part = NULL, *p;
unsigned long base;
int pages;
misc: sram-exec: Use aligned fncpy instead of memcpy 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 <tony@atomide.com> Acked-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Alexandre Belloni <alexandre.belloni@free-electrons.com> Signed-off-by: Dave Gerlach <d-gerlach@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-05-18 22:07:06 +07:00
void *dst_cpy;
drivers/misc: sram-exec: have the callers of set_memory_*() check the return value 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 <tli@digitalocean.com> Reviewed-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20191217194528.16461-1-tli@digitalocean.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-12-18 02:45:28 +07:00
int ret;
misc: sram: Introduce support code for protect-exec sram type 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 <d-gerlach@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-13 03:52:19 +07:00
mutex_lock(&exec_pool_list_mutex);
list_for_each_entry(p, &exec_pool_list, list) {
if (p->pool == pool)
part = p;
}
mutex_unlock(&exec_pool_list_mutex);
if (!part)
misc: sram-exec: Use aligned fncpy instead of memcpy 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 <tony@atomide.com> Acked-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Alexandre Belloni <alexandre.belloni@free-electrons.com> Signed-off-by: Dave Gerlach <d-gerlach@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-05-18 22:07:06 +07:00
return NULL;
misc: sram: Introduce support code for protect-exec sram type 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 <d-gerlach@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-13 03:52:19 +07:00
lib/genalloc.c: rename addr_in_gen_pool to gen_pool_has_addr 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 <sjhuang@iluvatar.ai> Reviewed-by: Andrew Morton <akpm@linux-foundation.org> Cc: Russell King <linux@armlinux.org.uk> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Christoph Hellwig <hch@lst.de> Cc: Marek Szyprowski <m.szyprowski@samsung.com> Cc: Robin Murphy <robin.murphy@arm.com> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-12-05 07:52:03 +07:00
if (!gen_pool_has_addr(pool, (unsigned long)dst, size))
misc: sram-exec: Use aligned fncpy instead of memcpy 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 <tony@atomide.com> Acked-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Alexandre Belloni <alexandre.belloni@free-electrons.com> Signed-off-by: Dave Gerlach <d-gerlach@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-05-18 22:07:06 +07:00
return NULL;
misc: sram: Introduce support code for protect-exec sram type 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 <d-gerlach@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-13 03:52:19 +07:00
base = (unsigned long)part->base;
pages = PAGE_ALIGN(size) / PAGE_SIZE;
mutex_lock(&part->lock);
drivers/misc: sram-exec: have the callers of set_memory_*() check the return value 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 <tli@digitalocean.com> Reviewed-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20191217194528.16461-1-tli@digitalocean.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-12-18 02:45:28 +07:00
ret = set_memory_nx((unsigned long)base, pages);
if (ret)
goto error_out;
ret = set_memory_rw((unsigned long)base, pages);
if (ret)
goto error_out;
misc: sram: Introduce support code for protect-exec sram type 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 <d-gerlach@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-13 03:52:19 +07:00
misc: sram-exec: Use aligned fncpy instead of memcpy 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 <tony@atomide.com> Acked-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Alexandre Belloni <alexandre.belloni@free-electrons.com> Signed-off-by: Dave Gerlach <d-gerlach@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-05-18 22:07:06 +07:00
dst_cpy = fncpy(dst, src, size);
misc: sram: Introduce support code for protect-exec sram type 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 <d-gerlach@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-13 03:52:19 +07:00
drivers/misc: sram-exec: have the callers of set_memory_*() check the return value 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 <tli@digitalocean.com> Reviewed-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20191217194528.16461-1-tli@digitalocean.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-12-18 02:45:28 +07:00
ret = set_memory_ro((unsigned long)base, pages);
if (ret)
goto error_out;
ret = set_memory_x((unsigned long)base, pages);
if (ret)
goto error_out;
misc: sram: Introduce support code for protect-exec sram type 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 <d-gerlach@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-13 03:52:19 +07:00
mutex_unlock(&part->lock);
misc: sram-exec: Use aligned fncpy instead of memcpy 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 <tony@atomide.com> Acked-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Alexandre Belloni <alexandre.belloni@free-electrons.com> Signed-off-by: Dave Gerlach <d-gerlach@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-05-18 22:07:06 +07:00
return dst_cpy;
drivers/misc: sram-exec: have the callers of set_memory_*() check the return value 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 <tli@digitalocean.com> Reviewed-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20191217194528.16461-1-tli@digitalocean.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-12-18 02:45:28 +07:00
error_out:
mutex_unlock(&part->lock);
return NULL;
misc: sram: Introduce support code for protect-exec sram type 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 <d-gerlach@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-13 03:52:19 +07:00
}
EXPORT_SYMBOL_GPL(sram_exec_copy);
Reference in New Issue Copy Permalink