Skip to content

Enhancement: Secureboot production signing of kernel modules using ephemeral keys + bug fixes #23406

@bhouse-nexthop

Description

@bhouse-nexthop

Is it platform specific

generic

Importance or Severity

Medium

Description of the enhancement

Kernel module ephemeral key signing support

The current sonic secureboot implementation assumes all assets are signed with the DB Key. There are roughly 3600 kernel modules that get signed in the process.

Organizations may have varying security policy requirements where any signing requests may require signoff by one or more parties, this may simply be infeasible for that many requests.

Given that the DB key may be a long-lived key, and only RSA 2048 is often used or available, it is a security best-practice to sign as few assets as possible with such a key.

Therefore it should be allowable to use an ephemeral key for signing kernel modules.

Sonic Image Signature Verification

The current signature verification of sonic images assumes the DB Keys are all Root CAs. The secureboot standard says nothing about this, the DBKeys are explicitly trusted by signing them with the KEK, and that signing method does not follow the standard X.509 PKI architecture. Therefore the DB Key is not guaranteed to be a CA Root (aka not self-signed). It is possible the DB Key was created as an intermediate, but since it is explicitly trusted that is ok.

The signature verification should explicitly trust the DB Key without needing to perform Root CA validation.

Bugs fixed

  • Loading of signed platform modules fails due to -f flag passed to modprobe as it invalidates the signature
  • SECURE_UPGRADE_MODE not over-writable by environment like other secureboot variables
  • SECURE_UPGRADE_PROD_TOOL_ARGS not quoted properly so only passes through first argument specified
  • Install signed grub/shim even if BIOS doesn't have secureboot enabled
  • Kernel module base search path isn't specific enough and ends up signing non-kernel-module files.

Current Behavior

Described above

Proposed Behavior

PRs:

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions