mirrors/linux-stable
1
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git synced 2024-10-30 08:02:30 +00:00
Code Issues Releases Wiki Activity
linux-stable/include/linux/sram.h

18 lines
437 B
C
Raw Normal View History

treewide: Replace GPLv2 boilerplate/reference with SPDX - gpl-2.0_30.RULE (part 2) Based on the normalized pattern: this program is free software you can redistribute it and/or modify it under the terms of the gnu general public license as published by the free software foundation version 2 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 extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference. Reviewed-by: Allison Randal <allison@lohutok.net> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-06-07 14:11:13 +00:00
/* SPDX-License-Identifier: GPL-2.0-only */
/* Generic SRAM Driver Interface */
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-12 20:52:19 +00:00
#ifndef __LINUX_SRAM_H__
#define __LINUX_SRAM_H__
struct gen_pool;
#ifdef CONFIG_SRAM_EXEC
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 15:07:06 +00: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-12 20:52:19 +00:00
#else
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 15:07:06 +00:00
static inline 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-12 20:52:19 +00: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 15:07:06 +00: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-12 20:52:19 +00:00
}
#endif /* CONFIG_SRAM_EXEC */
#endif /* __LINUX_SRAM_H__ */
Reference in a new issue Copy permalink