Searched hist:"9 ebe34b0007fc342d11d6c4bb2454048c9c3c154" (Results 1 – 3 of 3) sorted by relevance
| /optee_os/core/arch/arm/kernel/ |
| H A D | link_dummy.ld | 9ebe34b0007fc342d11d6c4bb2454048c9c3c154 Tue Jan 26 22:09:19 UTC 2021 Volodymyr Babchuk <volodymyr_babchuk@epam.com> link: make section size definitions relocation-proof
Value of define VCORE_UNPG_RW_SZ is determined by linker script and
provided to C code as a symbol value (__vcore_unpg_rw_size). This is a
standard way of sharing linker variables with C code, which is described in
ld manual.
Problem is that linker sometimes makes those symbols relocatable and ASLR
code then moves them to random places with rest of the OP-TEE image.
For example, on build for RCAR platform I am getting those entries in
relocation section:
[...]
000000004415b120 R_AARCH64_RELATIVE *ABS*+0x0000000044100180
000000004415af60 R_AARCH64_RELATIVE *ABS*+0x000000004415fc48
000000004415afb0 R_AARCH64_RELATIVE *ABS*+0x00000000000a4000 <======
000000004415aef8 R_AARCH64_RELATIVE *ABS*+0x000000004415c000
[...]
From programmer's point of view this looks like "constant" VCORE_UNPG_RW_SZ
has random value every boot.
Obvious approach is to provide section end address and then calculate size
on C side:
#define VCORE_UNPG_RW_SZ ((size_t)(__vcore_unpg_rx_end -
__vcore_unpg_rx_start))
But with this approach compiler can't initialize constant values in
definitions like
register_phys_mem_ul(MEM_AREA_TEE_RAM_RW, VCORE_UNPG_RW_PA,
VCORE_UNPG_RW_SZ);
from core_mmu.c.
Basically, this leads to following constraints:
1. If we calculate section size in linker script, then compiler can use
it as a constant expression, but this value may be mangled by ASLR
at run-time.
2. We can't calculate section size in C code, because this value can't be
used as a constant expression.
This patch provides a workaround around this issue by providing two sets of
definitions: old _SZ definition is renamed to _SZ_UNSAFE and it should be
used only in places where a constant expression is required and provided it
is referenced only before dynamic relocations have been applied, while the
new _SZ definition can be used in all other situations.
Value of _new SZ is obtained by deducting section start address from end
address. Additional linker symbols are introduced to provide section end
addresses.
Fixes: 170e9084a84f ("core: add support for CFG_CORE_ASLR")
Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>
Reviewed-by: Jerome Forissier <jerome@forissier.org>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
|
| H A D | kern.ld.S | 9ebe34b0007fc342d11d6c4bb2454048c9c3c154 Tue Jan 26 22:09:19 UTC 2021 Volodymyr Babchuk <volodymyr_babchuk@epam.com> link: make section size definitions relocation-proof
Value of define VCORE_UNPG_RW_SZ is determined by linker script and
provided to C code as a symbol value (__vcore_unpg_rw_size). This is a
standard way of sharing linker variables with C code, which is described in
ld manual.
Problem is that linker sometimes makes those symbols relocatable and ASLR
code then moves them to random places with rest of the OP-TEE image.
For example, on build for RCAR platform I am getting those entries in
relocation section:
[...]
000000004415b120 R_AARCH64_RELATIVE *ABS*+0x0000000044100180
000000004415af60 R_AARCH64_RELATIVE *ABS*+0x000000004415fc48
000000004415afb0 R_AARCH64_RELATIVE *ABS*+0x00000000000a4000 <======
000000004415aef8 R_AARCH64_RELATIVE *ABS*+0x000000004415c000
[...]
From programmer's point of view this looks like "constant" VCORE_UNPG_RW_SZ
has random value every boot.
Obvious approach is to provide section end address and then calculate size
on C side:
#define VCORE_UNPG_RW_SZ ((size_t)(__vcore_unpg_rx_end -
__vcore_unpg_rx_start))
But with this approach compiler can't initialize constant values in
definitions like
register_phys_mem_ul(MEM_AREA_TEE_RAM_RW, VCORE_UNPG_RW_PA,
VCORE_UNPG_RW_SZ);
from core_mmu.c.
Basically, this leads to following constraints:
1. If we calculate section size in linker script, then compiler can use
it as a constant expression, but this value may be mangled by ASLR
at run-time.
2. We can't calculate section size in C code, because this value can't be
used as a constant expression.
This patch provides a workaround around this issue by providing two sets of
definitions: old _SZ definition is renamed to _SZ_UNSAFE and it should be
used only in places where a constant expression is required and provided it
is referenced only before dynamic relocations have been applied, while the
new _SZ definition can be used in all other situations.
Value of _new SZ is obtained by deducting section start address from end
address. Additional linker symbols are introduced to provide section end
addresses.
Fixes: 170e9084a84f ("core: add support for CFG_CORE_ASLR")
Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>
Reviewed-by: Jerome Forissier <jerome@forissier.org>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
|
| /optee_os/core/arch/arm/mm/ |
| H A D | core_mmu.c | 9ebe34b0007fc342d11d6c4bb2454048c9c3c154 Tue Jan 26 22:09:19 UTC 2021 Volodymyr Babchuk <volodymyr_babchuk@epam.com> link: make section size definitions relocation-proof
Value of define VCORE_UNPG_RW_SZ is determined by linker script and
provided to C code as a symbol value (__vcore_unpg_rw_size). This is a
standard way of sharing linker variables with C code, which is described in
ld manual.
Problem is that linker sometimes makes those symbols relocatable and ASLR
code then moves them to random places with rest of the OP-TEE image.
For example, on build for RCAR platform I am getting those entries in
relocation section:
[...]
000000004415b120 R_AARCH64_RELATIVE *ABS*+0x0000000044100180
000000004415af60 R_AARCH64_RELATIVE *ABS*+0x000000004415fc48
000000004415afb0 R_AARCH64_RELATIVE *ABS*+0x00000000000a4000 <======
000000004415aef8 R_AARCH64_RELATIVE *ABS*+0x000000004415c000
[...]
From programmer's point of view this looks like "constant" VCORE_UNPG_RW_SZ
has random value every boot.
Obvious approach is to provide section end address and then calculate size
on C side:
#define VCORE_UNPG_RW_SZ ((size_t)(__vcore_unpg_rx_end -
__vcore_unpg_rx_start))
But with this approach compiler can't initialize constant values in
definitions like
register_phys_mem_ul(MEM_AREA_TEE_RAM_RW, VCORE_UNPG_RW_PA,
VCORE_UNPG_RW_SZ);
from core_mmu.c.
Basically, this leads to following constraints:
1. If we calculate section size in linker script, then compiler can use
it as a constant expression, but this value may be mangled by ASLR
at run-time.
2. We can't calculate section size in C code, because this value can't be
used as a constant expression.
This patch provides a workaround around this issue by providing two sets of
definitions: old _SZ definition is renamed to _SZ_UNSAFE and it should be
used only in places where a constant expression is required and provided it
is referenced only before dynamic relocations have been applied, while the
new _SZ definition can be used in all other situations.
Value of _new SZ is obtained by deducting section start address from end
address. Additional linker symbols are introduced to provide section end
addresses.
Fixes: 170e9084a84f ("core: add support for CFG_CORE_ASLR")
Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>
Reviewed-by: Jerome Forissier <jerome@forissier.org>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
|