UART Changes#

Fine-grained Access Control Using Custom Abilities for UART Resource Manager#

Target Changes

Backward Compatible

Platform

OS

In release 7.2.6.0, applications that access UART devnodes must be granted the required nvser/port custom abilities before they can use a UART devnode.

  • Safety builds (SR): Add the required nvser/port abilities to abilities.txt and launch the process with --secpol-type <policy_type>. iolauncher applies the abilities from the security policy; do not add -A nonroot,allow,able=nvser/port:... for UART access.

  • Standard builds (NSR): Grant the required nvser/port abilities directly in the iolauncher command using -A nonroot,allow,able=nvser/port:....

Without the required abilities, open(), read(), write(), and UART configuration operations (baud rate, parity, stop bits, and flow control) fail with a permission denied error.

Each UART devnode requires nvser/port abilities. The ability value uses the format 0x{devnode index}{operation}, where {devnode index} is the UART instance number in hexadecimal (the numeric suffix of the devnode name) and {operation} is:

  • 01 — READ

  • 02 — WRITE

  • 03 — CFG_BAUD

  • 04 — CFG_PARITY

  • 05 — CFG_STOPBITS

  • 06 — CFG_FLOWCTRL

For example, for /dev/ser10 (devnode index 0xA):

  • Read: nvser/port:0xA01

  • Write: nvser/port:0xA02

  • Read, write, and configuration: nvser/port:0xA01-0xA06

No

NSR, SR

QNX only

Migration Path

  • Orin to Thor

  • Thor to Thor

Migration Release Path

7.2.5.0 to 7.2.6.0

Migration Rationale

This change satisfies fine-grained access permission requirements (DOSMAIN-REQ-213) for UART. Customers must update the launch configuration, and safety builds must also update abilities.txt, before using UART devnodes in release 7.2.6.0.

Steps to Migrate

  1. Identify every process that accesses UART devnodes directly (for example, /dev/ser10).

  2. For each UART devnode the process must use, determine the required nvser/port ability values from the devnode index and operation codes listed above. Grant only the abilities needed (read, write, and/or configuration).

  3. Update the security policy (abilities.txt) for safety builds.

    Safety builds (SR)

    All UART devnodes that a process accesses must be specified with the nvser/port ability in abilities.txt. A process can only access UART devnodes listed in its allow <type> self:ability block.

    For example, to grant read, write, and configuration access to /dev/ser10:

    allow my_uart_app_t self:ability {
    noinherit
    unlock
    nonroot
    pathspace
    public_channel
    # /dev/ser10 — read, write, and configuration
    nvser/port:0xA01-0xA06
};

    To grant read-only access to /dev/ser10:

    allow my_uart_app_t self:ability {
    noinherit
    unlock
    nonroot
    pathspace
    public_channel
    # /dev/ser10 — read only
    nvser/port:0xA01
};

    The ability can be specified as a single value or a range. Repeat the entry for each additional UART devnode the process must access.

  4. Update the process launch configuration.

    Safety builds (SR)

    Launch the process with --secpol-type set to the security policy type defined in abilities.txt. iolauncher grants the abilities from that policy type, including nvser/port.

    For example, for a process that accesses /dev/ser10 and uses the my_uart_app_t security policy type:

    iolauncher --secpol-type my_uart_app_t -U <uid>:<gid>,... <application>

    Add --secpol-type to the existing iolauncher launch command for that process. Keep all other launch options unchanged.

    Standard builds (NSR)

    Grant the required nvser/port abilities directly in the iolauncher command. Add a new -A nonroot,allow,able=nvser/port:... option to the existing launch command. Keep all other launch options unchanged.

    For /dev/ser10, add the nvser/port ability for the access required by the application. For example, to grant read, write, and configuration access to /dev/ser10:

    iolauncher -U <uid>:<gid>,... \
  -A nonroot,allow,able=nvser/port:0xA01-0xA06 \
  <application>

    Append the nvser/port -A option alongside any existing -A options in the launch command. The ability can be specified as a single value or a range. Replace <uid>:<gid> and <application> with the values from your launch configuration.

  5. Rebuild and deploy the updated IFS image. For safety builds, also rebuild and deploy the updated security policy.

  6. Revalidate UART access flows. Confirm that:

    • Processes with the required abilities can open, read, write, and configure the intended UART devnodes.

    • Processes without the required abilities receive permission denied when attempting the corresponding operation. For example, if an application lacks read permission for /dev/ser10 (nvser/port:0xA01), a read() on that device fails.

For additional information about the QNX serial driver and launch configuration, refer to the NVIDIA DriveOS SDK Developer Guide.