Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mbed TLS cannot be built with AES-XTS support #2254

Closed
ainaracatgirl opened this issue Feb 11, 2025 · 4 comments
Closed

Mbed TLS cannot be built with AES-XTS support #2254

ainaracatgirl opened this issue Feb 11, 2025 · 4 comments

Comments

@ainaracatgirl
Copy link

I'm trying to use the built-in pico_mbedtls library to use Mbed TLS to encrypt data using AES-XTS.

However, no matter what I try, the result remains same: no error when compiling my code, but an error at linking because it cannot find the XTS-related symbols.

I have tried adding the MBEDTLS_CIPHER_MODE_XTS=1 define in every possible way: into CMAKE_C_FLAGS, inside mbedtls_config.h, with add_compile_definitions(...) and both target_compile_definitions(pico_mbedtls_crypto INTERFACE ...) and target_compile_definitions(pico_mbedtls INTERFACE ...).

/path/to/ld: CMakeFiles/path/to/kmain.c.o: in function `aes256_xts_test':
/path/to/bench.c:76:(.text.aes256_xts_test+0x10): undefined reference to `mbedtls_aes_xts_init'
/path/to/ld: /path/to/bench.c:77:(.text.aes256_xts_test+0x1c): undefined reference to `mbedtls_aes_xts_setkey_enc'
/path/to/ld: /path/to/bench.c:83:(.text.aes256_xts_test+0x46): undefined reference to `mbedtls_aes_crypt_xts'
/path/to/ld: /path/to/bench.c:87:(.text.aes256_xts_test+0x5a): undefined reference to `mbedtls_aes_xts_setkey_dec'
/path/to/ld: /path/to/bench.c:93:(.text.aes256_xts_test+0x7e): undefined reference to `mbedtls_aes_crypt_xts'
/path/to/ld: /path/to/bench.c:104:(.text.aes256_xts_test+0xa4): undefined reference to `mbedtls_aes_xts_free'
collect2: error: ld returned 1 exit status

(yes, I am importing bench.c directly from kmain.c without using a header file as this is a temporary test that will get removed afterwards)

The relevant parts of my CMakeLists.txt are the following (with the project name replaced with ProjectNameHere):

cmake_minimum_required(VERSION 3.13)
include(pico_sdk_import.cmake)

set(CMAKE_C_STANDARD 11)
set(CMAKE_EXPORT_COMPILE_COMMANDS ON)

project(ProjectNameHere)
pico_sdk_init()

target_compile_definitions(pico_mbedtls_crypto INTERFACE MBEDTLS_CIPHER_MODE_XTS=1)
target_compile_definitions(pico_mbedtls INTERFACE MBEDTLS_CIPHER_MODE_XTS=1)

set(MBEDTLS_USER_CONFIG_FILE "${CMAKE_CURRENT_LIST_DIR}/src/mbedtls_config.h")
set(PICO_MBEDTLS_CONFIG_FILE "${CMAKE_CURRENT_LIST_DIR}/src/mbedtls_config.h")
add_compile_definitions(MBEDTLS_CIPHER_MODE_XTS=1)

add_executable(ProjectNameHere
  src/kmain.c
)

target_link_libraries(ProjectNameHere
  pico_stdio pico_stdlib pico_rand
  hardware_exception hardware_watchdog hardware_clocks
  pico_sha256 pico_mbedtls
)

target_include_directories(ProjectNameHere PRIVATE src/)

pico_enable_stdio_usb(ProjectNameHere 1)
pico_enable_stdio_uart(ProjectNameHere 1)

pico_set_program_name(ProjectNameHere "Project Name Here")
pico_set_program_version(ProjectNameHere "1.0")
pico_add_extra_outputs(ProjectNameHere)

Is there something wrong in my end, or is this a shortcoming of the SDK's design?

Thanks in advance,
Ainara Garcia

@peterharperuk
Copy link
Contributor

Sorry, I can't explain your problem. I modified one of the examples to call mbedtls_aes_xts_init and it worked as expected, no linker errors. Try building with VERBOSE=1 and see how aes.c is being built

@ainaracatgirl
Copy link
Author

Well the line itself where the compiler is called is 8 KB in length, but i can see -DMBEDTLS_CIPHER_MODE_XTS=1 in it, so that's weird...

And in the specific submodule commit/branch of Mbed TLS used by pico-sdk, I can see the following in aes.c at line 513.

#if defined(MBEDTLS_CIPHER_MODE_XTS)
void mbedtls_aes_xts_init(mbedtls_aes_xts_context *ctx)
{
    AES_VALIDATE(ctx != NULL);

    mbedtls_aes_init(&ctx->crypt);
    mbedtls_aes_init(&ctx->tweak);
}

So I myself can't see why this isn't working, I guess I'll have to investigate deeper into how exactly the binary is being linked to find the issue.

@ainaracatgirl
Copy link
Author

For the building of aes.c, CMakeFiles/path/to/pico-sdk/lib/mbedtls/library/aes.c.o is 1.9 KB and contains no symbols whatsoever by the output of arm-none-eabi-objdump -t:

SYMBOL TABLE:
00000000 l    df *ABS*	00000000 aes.c
00000000 l    d  .text	00000000 .text
00000000 l    d  .data	00000000 .data
00000000 l    d  .bss	00000000 .bss
00000000 l    d  .debug_info	00000000 .debug_info
00000000 l    d  .debug_abbrev	00000000 .debug_abbrev
00000000 l    d  .debug_aranges	00000000 .debug_aranges
00000000 l    d  .debug_line	00000000 .debug_line
00000000 l    d  .debug_str	00000000 .debug_str
00000000 l    d  .comment	00000000 .comment
00000000 l    d  .ARM.attributes	00000000 .ARM.attributes

The compiler is invoked as

arm-none-eabi-gcc [...] -DMBEDTLS_CIPHER_MODE_XTS=1 [...] -o CMakeFiles/path/to/pico-sdk/lib/mbedtls/library/aes.c.o -c /path/to/pico-sdk/lib/mbedtls/library/aes.c

And the aes.c file does indeed contain the check for the XTS define, I genuinely have no idea how this could be happening.

As for the linking of the main ELF binary, the path to aes.c.o is included in the command, so it must be linking against it, there really seems like there isn't an explanation to this.

@ainaracatgirl
Copy link
Author

Ah, I got it working, sorry for the annoyance, just define MBEDTLS_AES_C=1 as it's not defined by default and of course that means the whole aes.c file was being ignored, that's why it was so small in size.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants