ASLR seed, XLAT tables and configuration

[RNNord2]

Hi. I'm building optee-os version 4.5.0 for an imx8mp target. I have the following configuration settings passed as make arguments in a Yocto recipe:

PLATFORM=imx-mx8mpevk CFG_TEE_CORE_LOG_LEVEL=4 CFG_DDR_SIZE=0x100000000 CFG_TZDRAM_START=0xFE000000 CFG_TZC380=y CFG_UART_BASE=${ATF_AND_OPTEE_UART_BASE} CFG_DT_ADDR=${OPTEE_OS_CFG_DT_ADDR} CFG_DT=y CFG_EXTERNAL_DTB_OVERLAY=y CFG_NXP_CAAM=y CFG_NXP_CAAM_BLOB_DRV=y CFG_NXP_CAAM_SM_DRV=y CFG_NXP_CAAM_RNG_DRV=y CFG_DBG_CAAM_TRACE=0xFFFF CFG_CORE_ASLR=y CFG_CRYPTO_DRIVER=y CFG_NXP_CAAM_AE_GCM_DRV=y CFG_NXP_CAAM_AE_CCM_DRV=y

My first question is how you would recommend to provide the ASLR seed for imx8mp, since the CAAM module is not initiated at the time optee-os calls plat_get_aslr_seed (we cannot use crypto_rng_read). What is the restrictions, if any, on the provided seed? I tried to just hard-code a number of different seeds in plat_get_aslr_seed, but then the optee-os startup hangs with:

D/TC:0 core_mmu_xlat_table_alloc:527 xlat tables used 7 / 8
D/TC:0 core_mmu_xlat_table_alloc:527 xlat tables used 8 / 8
E/TC:0 assertion 'user_va_idx != -1' failed at [.......]/core/arch/arm/mm/core_mmu_lpae.c:712 <set_user_va_idx>
E/TC:0 Panic at [.......]/core/kernel/assert.c:28 <_assert_break>

The second question relates to MAX_XLAT_TABLES. If I disable ASLR (using CFG_CORE_ASLR=n in the config settings above), I'm getting:

optee optee: OP-TEE: revision 4.5 (919de0f7c79ad35)
I/TC: Reserved shared memory is enabled
I/TC: Dynamic shared memory is enabled
I/TC: Normal World virtualization support is disabled
I/TC: Asynchronous notifications are disabled
E/TC:0 0 core_mmu_xlat_table_alloc:520 5 xlat tables exhausted
E/TC:0 0 Panic 'Failed to spread pgdir on small tables' at [.......]/core/mm/core_mmu.c:2031 <core_mmu_map_pages>

This happens at later stage, during U-boot startup. I can see how MAX_XLAT_TABLES are set and added to with various dependencies in the source code. I could obviously change that (and the system will boot just fine), but I would like to know if anything is wrong with my configuration since I'm getting this error. How would you recommend to make sure that MAX_XLAT_TABLES is big enough?

If I have missed any part of the optee-os documentation providing answers to my question, please guide me to the right documents. Your help is much appreciated.

[jenswi-linaro]

Have you made any local changes? Can you start from something that works? Increasing MAX_XLAT_TABLES should address the "xlat tables exhausted" problem.

[RNNord2]

Thank you. The only local change I have is that I've added this to core/arch/arm/plat-imx/main.c:

#ifdef CFG_CORE_ASLR  
unsigned long plat_get_aslr_seed(void) 
{ 
    unsigned long seed = 0; 
    DMSG("Getting platform specific ASLR seed\n");

    /* TODO: How to get a random seed (CAAM is not initialized), and what is the legal range of the seed? */
    return seed;
}
#endif

Obviously it currently does the same as the __weak function provided in optee-os (return zero).

Yes, the "xlat table exhausted" problem goes away with CFG_CORE_ASLR=y, but I guess that is just because:

#ifdef CFG_CORE_ASLR
#	define XLAT_TABLE_ASLR_EXTRA 3
#else

in core_mmu_lpae.c.

Your suggestion is just to patch in a custom higher value to MAX_XLAT_TABLES or to pass it as a define to the compiler (if possible)? I can do that and I'm fine with that if you think it is the proper way. I was just concerned that since the problem occurred in the first place I might have done some configuration mistake since MAX_XLAT_TABLES is indirectly affected by some other configuration parameters as well.

If you have some comments about the ASLR seed issue as well, that would be great. Thank you.

[jenswi-linaro]

You can override MAX_XLAT_TABLES in platform_config.h if needed.
Since CAAM isn't initialized yet you need to get a random seed by other means, perhaps Arm SMCCC TRNG if that interface is available in TF-A for your platform.

[RNNord2]

Thank you for your help, much appreciated. I will override MAX_XLAT_TABLES with a higher value to solve that issue.

Regarding ASLR, I will disable it for now since assigning a non-zero value to the ASLR seed gives the issue initially reported:

E/TC:0 assertion 'user_va_idx != -1' failed at [.......]/core/arch/arm/mm/core_mmu_lpae.c:712 <set_user_va_idx>
E/TC:0 Panic at [.......]/core/kernel/assert.c:28 <_assert_break>

It happens here, in core/arch/arm/mm/core_mmu_lpae.c:

	/*
	 * Search level 1 table (i.e. 1GB mapping per entry) for
	 * an empty entry in the range [1GB, 4GB[.
	 */
	for (n = 1; n < 4; n++) {
		if ((tbl[n] & DESC_ENTRY_TYPE_MASK) == INVALID_DESC) {
			user_va_idx = n;
			break;
		}
	}

	assert(user_va_idx != -1);

If the loop range is extended beyond 4 the error goes away and the system boot completes, but reading #7194 I understand that it's neither desired nor allowed to do that (and there will be 'panic' when running xtest later anyway). So, it remains unknown to me how I could make ASLR work with a non-zero seed provided.

[jenswi-linaro]

This means you're somehow using all the top-level mappings below 4GB. Do you need to map that much?

[RNNord2]

Actually, I've not done any specific/intentional memory mappings/configurations besides the ones showed in my CFG_ parameters and what is originally set in optee by selecting PLATFORM=imx-mx8mpevk. I have CFG_DDR_SIZE=0x100000000 and CFG_TZDRAM_START=0xFE000000, and I have optee-os loaded at physical address 0xFE000000.

The rationale behind 0xFE000000 was to place optee-os and it's memory areas near the end of the 4GB memory. Is this what might cause the ASLR issue I'm facing, or do I misunderstand? I've noticed that in meta-freescale the tee load address is instead 0x56000000 for imx8mp.

[jenswi-linaro]

You may want to take a look in the log to see what you're mapping.

[RNNord2]

OK, I'll check what is mapped. For information, it seems that the described ASLR issue went away when I located optee-os at a lower address (like 0x56000000 as done in meta-freescale). Thank you for your help; I think we can close this issue.