'Disable UART Intel Processor

I have a custom device that uses an Intel Celeron N3350 processor, following a security penetration test it was observed that we need to disable our UART debug port. Ideally we still provide a means for developers/QA to be able to toggle the port on/off.

System Details:

  • Intel Celeron N3350 processor
  • Gigabyte motherboard, AMI BIOS
  • Yocto Linux Kernel 4.19, branch warrior
  • GRUB2 2.02 bootloader

Initial approach was to modify bootloader parameters, specifically the console= parameter, but this configuration file is maintained in read-only memory (thus making toggling the port on/off much more difficult). The boot parameters are as follows (from cat /proc/cmdline.

BOOT_IMAGE=<path-to-vmlinuz>/vmlinuz rootfstype=ext4 ramdisk_size=32768 rootwait console=ttyS2,115200n8 reboot=efi snd_hda_intel.power_save=1 snd_hda_intel.power_save_controller=y scsi_mod.scan=async i915.enable_guc=2 i915.fastboot=1 intel_iommu=on,ipu_off loglevel=3 rd.systemd.show_status=false logo.nologo vt.global_cursor_default=0 plymouth.ignore-serial-consoles splash

The next approach was to manage the UART port at the kernel level (e.g. systemctl, udev). A systemctl -a | grep tty shows the following below. I'm still learning systemd, but it appears that the UART devices are associated to the console ports.

  dev-ttyS0.device                                                                              loaded    active   plugged   Celeron N3350/Pentium N4200/Atom E3900 Series HSUART Controller                            
  dev-ttyS1.device                                                                              loaded    active   plugged   Celeron N3350/Pentium N4200/Atom E3900 Series HSUART Controller                            
  dev-ttyS2.device                                                                              loaded    active   plugged   Celeron N3350/Pentium N4200/Atom E3900 Series HSUART Controller                            
  dev-ttyS3.device                                                                              loaded    active   plugged   Celeron N3350/Pentium N4200/Atom E3900 Series HSUART Controller                            
  sys-devices-pci0000:00-0000:00:18.0-dw\x2dapb\x2duart.8-tty-ttyS0.device                      loaded    active   plugged   Celeron N3350/Pentium N4200/Atom E3900 Series HSUART Controller                            
  sys-devices-pci0000:00-0000:00:18.1-dw\x2dapb\x2duart.9-tty-ttyS1.device                      loaded    active   plugged   Celeron N3350/Pentium N4200/Atom E3900 Series HSUART Controller                            
  sys-devices-pci0000:00-0000:00:18.2-dw\x2dapb\x2duart.10-tty-ttyS2.device                     loaded    active   plugged   Celeron N3350/Pentium N4200/Atom E3900 Series HSUART Controller                            
  sys-devices-pci0000:00-0000:00:18.3-dw\x2dapb\x2duart.11-tty-ttyS3.device                     loaded    active   plugged   Celeron N3350/Pentium N4200/Atom E3900 Series HSUART Controller                            
  [email protected]                                                                    loaded    active   running   Serial Getty on ttyS0                                                                      
  [email protected]                                                                    loaded    active   running   Serial Getty on ttyS1                                                                      
● [email protected]                                                                    masked    inactive dead      [email protected] 

I've tried disabling all of the serial consoles, e.g. systemctl stop [email protected] then systemctl disable [email protected], expecting that the UART port would also cease functioning. But that was not the case.

So I suppose my question has two parts.

  1. Is it feasible to attempt to disable UART port via systemd managers (e.g. systemctl or udev)? This is advantageous because starting/stopping services is straightforward.
  2. If 1. is not feasible, is there a better direction that I should pursue/research?


Sources

This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.

Source: Stack Overflow

Solution Source