I am using verdin imx8mp, tdx-reference-minimal-image with the meta-toradex-security layer.
We have recently been doing a security review and it was noted about making u-boot messages silent as they output memory addresses and thing that could be used by an attacker to determine targeted attack vectors.
I have a patch for Linux kernel config and added the ‘silent=1’ to the kernel command line. But that only appears to affect the output from the second stage of u-boot.
Is there an easy way to make this apply to the first stage of u-boot and the main Linux kernel boot?
Ideally nothing should be output on the console if at all possible.
Also is it possible to silence the dmesg output on the console? Not sure if relevant but we are using the uart console where this is happening.
Hi, I’m the Toradex AI Assistant. I’m in early beta, and I would appreciate your feedback.
The Toradex Support team will follow up with you shortly!
Did you like my answer?
Hello,
To address your concerns about silencing U-Boot messages for security reasons on a Verdin iMX8MP module, you can indeed make the U-Boot console silent to prevent the display of potentially sensitive information during boot. This involves configuring U-Boot to suppress console output.
Silencing U-Boot
Modify U-Boot Configuration: You’ve already noted adding silent=1 to the kernel command line affects the second stage of U-Boot. To extend this silence to the earliest stages of U-Boot, you need to modify the U-Boot configuration directly in the source before it’s compiled. This involves setting the CONFIG_SILENT_CONSOLE, CONFIG_SYS_DEVICE_NULLDEV, CONFIG_SILENT_CONSOLE_UPDATE_ON_RELOC, and potentially other silent-related configurations in the U-Boot configuration files (defconfig for your board) and ensuring these settings are enabled.
Recompile U-Boot: After making the necessary changes to the configuration files, recompile U-Boot and deploy it to your Verdin iMX8MP module. This will ensure that the console is silent from the earliest boot stages.
Silencing Linux Kernel Output
Since you’ve added silent=1 to the kernel command line and are looking to silence the output from the Linux kernel as well, ensure that the console= kernel parameter is set appropriately to prevent console messages. Setting console=null as you’ve done should suppress most messages, but some early boot messages might still appear before the kernel command line parameters are processed.
Silencing dmesg Output
To silence dmesg output on the console:
You can use the kernel command line parameter loglevel=0 to adjust the verbosity of messages shown on the console. The loglevel parameter controls the kernel’s console log level; setting it to 0 should silence all messages, except for emergency messages (panic or oops).
Additionally, for runtime control, you can adjust the console log level via the dmesg command: dmesg -n 1 sets the system log level to only show emergency messages to the console.
Summary
By adjusting U-Boot’s configuration to enable silent console features and setting the appropriate kernel command line parameters, you can minimize the amount of information displayed during boot. This helps mitigate the risk of exposing sensitive information that could be leveraged in targeted attacks.
Please ensure to test these configurations thoroughly to confirm that they meet your security
Please, also check if these links can help you solve your problem:
I believe I have all of these in place and it would appear it was not working.
The only difference I had (which I have now changed to test) is:
CONFIG_SILENT_U_BOOT_ONLY=y
I believe this is probably avoiding the silencing of the kernel loading.
If I am reading the docs correctly…
Then the console=... change should automatically be applied (except when the above mentioned config is defined).
My only other question to this is…
Currently my additions to the u-boot config are done via a custom.cfg file in the u-boot-toradex recipe and included via a bbappend.
Is this the correct way to do it? as the documentation linked suggests actually modifying the source config file with the definitions (however, that doesn’t seem to be targeted towards yocto builds).
Just want to check that the same process that applies to the linux kernel config is also used for the u-boot process.
I have now applied and tested my recent changes and found that the silencing does indeed change a lot when making the console=null change.
However, there is still a lot of early boot messages. The main one highlighted in our recent security review was that the memory location of unit and the kernel are displayed in terminal before everything goes silent.
Is there any extra places where things can be silenced? I am wondering if maybe another layer we depend on is doing something that we will need to patch.
Any pointer to anything in the code or config for me to look at to fully silence things would be helpful.
If this is not possible then is there any reference documentation that says this so I can go back to reviewer and “prove” it is not possible to follow their recommendations.
Can you share what output you currently have at boot?
Please also highlight the problematic part, so we can better understand which part of the boot process is displaying it.
I am now back in the office and have been able to get a log of the current output…
U-Boot SPL 2022.04-6.7.0+git.7588eb559ca2 (May 28 2024 - 11:19:14 +0000)
DDRINFO: start DRAM init
DDRINFO: DRAM rate 4000MTS
Training FAILED
DDRINFO: start DRAM init
DDRINFO: DRAM rate 4000MTS
DDRINFO:ddrphy calibration done
DDRINFO: ddrmix config done
DDR configured as single rank
SEC0: RNG instantiated
Normal Boot
WDT: Started watchdog@30280000 with servicing (60s timeout)
Trying to boot from BOOTROM
Boot Stage: Primary boot
Find img info 0x&48026c00, size 20480 <<< This was noted as providing info about the image
Need continue download 19456
Download 883200, Total size 903440
hab fuse not enabled
Authenticate image from DDR location 0x401fadc0... <<< this was noted as giving a very clear indication of where the image is located
NOTICE: BL31: v2.6(release):lf_v2.6-g3c1583ba0a
NOTICE: BL31: Built : 11:00:38, Nov 21 2022
Not sure if these are big issues, but as they were highlighted we need to either get validation that they are irrelevant, or find a way to silence them.
The addresses seem to be actual locations in the system RAM and to use such information an attacker would need a way to directly address the system RAM.
This output is from u-boot, so you would either need to remove these print statements from u-boot or redirect u-boot’s stdout.
