Skip to content

Securing Debug UART Access

Variscite Evaluation Kits and the provided Recovery SD Cards permit root access via the Serial Debug UART. You can simply login as root without a password and then start commands interactively.

While this is practical during evaluation and development, leaving such an option should be considered a serious security risk.

This page lists a few options that you can use to prevent write access to the terminal. Please have a look at the options and consider which method(s) are most suitable for you use-case.

Warning

This page is about access to the Linux Terminal using the Debug UART. Please also have a look the pages to deactivate or restrict SSH access and to Secure Access to the U-Boot Bootloader.

Why only RXD?

In the following two sections we will describe how to deactivate the RXD signal from the Debug UART.

One might ask: What about the TXD signal?

RXD is the input to the Debug UART, so keyboard input is read from that signal. Only RXD can be misused by a hacker to write terminal input and therefore execute commands via the serial console. Without the ability to write commands, everything that is displayed on the serial console might still be helpful during debugging.

If you consider the information that is output on the serial console to be sensitive, you can also deactivate the TXD signal.

Remove Physical Access - Don't Connect From the SOM Connector

The Debug UART RXD signal is on Pin #83 on the SOM connector. On Evaluation Kits, this signal is routed to a FT232R USB to Serial converter which allows easy access to any computer with a USB port.

If you remove the FT232R chip or don't connect the RXD signal, this access method is no longer possible.

This has one huge advantage:

  • It cannot be undone in software by a hacker.

This has one huge disadvantage:

  • It cannot be undone in software if you need this for debugging purposes.

Consider your options - what could a hacker be willing to do

Assume you have used an FT232R in the layout for your carrier board but have removed it for the final product. A hacker might discover that the FT232R has been removed and could solder their own USB-to-serial converter to these pads.

If you are concerned about this, consider not layouting the Debug UART RXD at all and/or consider additional listed methods.

Configure SoC Pads

When the Linux Kernel starts, it will parse the Device Tree and will configure the pads of the System-on-Chip accordingly. In its default configuration, the Debug UART TXD and RXD are configured in their function as UART.

You can see this in the following Device Tree file: 

    main_uart0_pins_default: main-uart0-default-pins {
        pinctrl-single,pins = <
            AM62PX_IOPAD(0x1c8, PIN_INPUT, 0)   /* (A22) UART0_RXD */
            AM62PX_IOPAD(0x1cc, PIN_OUTPUT, 0)  /* (B22) UART0_TXD */
        >;
        bootph-all;
    };

If you switch the entry for the RXD, the Debug UART's input channel will be deactivated.

            AM62PX_IOPAD(0x1c8, PIN_INPUT, 7)   /* (A22) now a GPIO */

Warning

You only deactivate the UART RXD communication from the moment that the kernel starts. Your U-Boot bootloader might still allow the interruption of the boot process via UART RXD communication. Please see the U-Boot guide for information on how to lock down access to the U-Boot bootloader.

Deactivate the Login Prompt of the Console

If you build a system with Yocto, it will boot and will eventually come to a login prompt. The system has been configured to have a login prompt, but it is possible to deactivate this behavior.

Info

This affects only the serial console login, not logins via SSH

Deactivate the Login Prompt of the Console at Runtime

You can use this behavior if you require the serial console to be enabled during the final manufacturing steps, but want to have it deactivated afterwards.

The login prompt can be deactivated at runtime with the following calls:

# systemctl mask [email protected]
# systemctl stop [email protected]

When you make the call with stop, console access is immediately aborted.

When you make the call with mask, access is restricted from the next boot. You can undo this operation with unmask.

The serial-getty service is not a normal service as it is enabled implicitly through the kernel command line. Therefor a call of systemctl stop [email protected] will not work.

Deactivate the Login Prompt at Build Time

There are two ways to deactivate the login prompt at build time.

The first version mimics the manual call by creating a symbolic link:

# ln -s /dev/null /etc/systemd/system/[email protected]

Make sure that this is executed during your image creation (as part of an installed recipe or in a post-image creation step).

The alternative is to add the kernel command line parameter systemd.getty_auto=no.

If you follow the setting provided by Variscite, you can achieve this by modifying the pre-configured U-Boot environment, e.g. by editing the environment file

args_all=run ramsize_check; setenv optargs ${optargs} earlycon=ns16550a,mmio32,0x02800000 ${cma_size} cma_name=linux,cma systemd.getty_auto=no

User Logins and Passwords

The SD Recovery Card is shipped as an open system. The root account has no password, so when logging in as root you don't even have to enter a password.

The empty root password is set because of the EXTRA_IMAGE_FEATURES debug-tweaks which is configured as a default option in local.conf when a build directory is initially set up.

When debug-tweaks is removed, there is still the option of empty-root-password that will also set up a system without a root password.

You can determine the current setting and where explicit configuration settings are made by using the following command at a build prompt:

# bitbake -e > enviro

Afterwards you can analyse the resulting file enviro, look for EXTRA_IMAGE_FEATURES.

Setting passwords during initial boot

If your deployment plan is based on booting a system before it is being shipped to the customer, it is an option to change the password during the initial boot. This also has the advantage that you can build one image but later set individual passwords during the first initial boot.

This can be done with the following command.

Warning

Normally, all executed commands that are started from the command line are included in the bash history. If you prefix a single space before the actual command, this command is not included in the bash history. Commands that are executed as part of a script are also not included.

# echo "Command without space is included in Bash History. The next line isn't"
#  echo -e 'new_root_password\nnew_root_password' > passwd root
New password: Retype new password: passwd: password updated successfully

Setting Password during Image Creation

Yocto has a special class that allows to generate multiple additional users during build time, but also to set passwords for these accounts, including the root password.

This is achieved by inheriting the extrausers class from your Yocto image recipe. Please see the extrausers documentation for additional information.