Searched hist:b2f99d2027f68858f842fef0dcfb348e46f7bd95 (Results 1 – 3 of 3) sorted by relevance
| /optee_os/core/include/kernel/ |
| H A D | boot.h | b2f99d2027f68858f842fef0dcfb348e46f7bd95 Thu Feb 01 14:04:23 UTC 2024 Olivier Deprez <olivier.deprez@arm.com> core: boot: fix memtag init sequence
Based on following observations on FVP:
With boot_init_memtag called before MMU enable, DC GZA hits an alignment
fault. This is because all accesses are of device type when MMU is off.
Arm ARM states for DC GZA: "If the memory region being modified is any
type of Device memory, this instruction can give an alignment fault."
Moving boot_init_memtag after MMU enable, DC GZA hits a permission
fault, this is because the range returned by core_mmu_get_secure_memory
consists of pages mapped RO (text sections) and then RW (data sections)
consecutively. DC GZA is a write instruction executed towards an RO page
leading to a fault.
To fix this, split boot_init_memtag into two halves:
- Setup memtag operations before MMU is enabled such that MAIR_EL1 is
properly configured for normal tagged memory.
- Clear core TEE RW sections after MMU is enabled.
Closes: https://github.com/OP-TEE/optee_os/issues/6649
Signed-off-by: Olivier Deprez <olivier.deprez@arm.com>
[jw rewrote boot_clear_memtag()]
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
Acked-by: Jerome Forissier <jerome.forissier@linaro.org>
Acked-by: Etienne Carriere <etienne.carriere@foss.st.com>
|
| /optee_os/core/arch/arm/kernel/ |
| H A D | entry_a64.S | b2f99d2027f68858f842fef0dcfb348e46f7bd95 Thu Feb 01 14:04:23 UTC 2024 Olivier Deprez <olivier.deprez@arm.com> core: boot: fix memtag init sequence
Based on following observations on FVP:
With boot_init_memtag called before MMU enable, DC GZA hits an alignment
fault. This is because all accesses are of device type when MMU is off.
Arm ARM states for DC GZA: "If the memory region being modified is any
type of Device memory, this instruction can give an alignment fault."
Moving boot_init_memtag after MMU enable, DC GZA hits a permission
fault, this is because the range returned by core_mmu_get_secure_memory
consists of pages mapped RO (text sections) and then RW (data sections)
consecutively. DC GZA is a write instruction executed towards an RO page
leading to a fault.
To fix this, split boot_init_memtag into two halves:
- Setup memtag operations before MMU is enabled such that MAIR_EL1 is
properly configured for normal tagged memory.
- Clear core TEE RW sections after MMU is enabled.
Closes: https://github.com/OP-TEE/optee_os/issues/6649
Signed-off-by: Olivier Deprez <olivier.deprez@arm.com>
[jw rewrote boot_clear_memtag()]
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
Acked-by: Jerome Forissier <jerome.forissier@linaro.org>
Acked-by: Etienne Carriere <etienne.carriere@foss.st.com>
|
| H A D | boot.c | b2f99d2027f68858f842fef0dcfb348e46f7bd95 Thu Feb 01 14:04:23 UTC 2024 Olivier Deprez <olivier.deprez@arm.com> core: boot: fix memtag init sequence
Based on following observations on FVP:
With boot_init_memtag called before MMU enable, DC GZA hits an alignment
fault. This is because all accesses are of device type when MMU is off.
Arm ARM states for DC GZA: "If the memory region being modified is any
type of Device memory, this instruction can give an alignment fault."
Moving boot_init_memtag after MMU enable, DC GZA hits a permission
fault, this is because the range returned by core_mmu_get_secure_memory
consists of pages mapped RO (text sections) and then RW (data sections)
consecutively. DC GZA is a write instruction executed towards an RO page
leading to a fault.
To fix this, split boot_init_memtag into two halves:
- Setup memtag operations before MMU is enabled such that MAIR_EL1 is
properly configured for normal tagged memory.
- Clear core TEE RW sections after MMU is enabled.
Closes: https://github.com/OP-TEE/optee_os/issues/6649
Signed-off-by: Olivier Deprez <olivier.deprez@arm.com>
[jw rewrote boot_clear_memtag()]
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
Acked-by: Jerome Forissier <jerome.forissier@linaro.org>
Acked-by: Etienne Carriere <etienne.carriere@foss.st.com>
|