RE: [EXT] Re: [PATCH v51 5/7] firmware: imx: adds miscdev

[Pankaj Gupta]

> - Who has reviewed the user interface from outside of NXP?
>   Since this is not a vendor-independent API, I think we have
>   to be extra careful and make sure this does not duplicate
>   anything that is already in the standard firmware interfaces.
>
> - Why is there a low-level passthrough to the firmware from
>   userspace? This looks rather irregular, since it is the kernel's
>   job to abstract the platform and provide vendor-independent
>   interfaces. In particular the bit about shared memory and
>   the generic send/receiv ioctl look like they should not
>   be there, as those would allow side-channels from userspace.

Let me answer at the level I think you are asking rather than with
driver internals.

On review from outside NXP:

- Marco Felsch & Sascha (Pengutronix) reviewed the interface
  across earlier revisions and I addressed their comments, although
  it carries no external Reviewed-by.

- Rob Herring's Reviewed-by on 2/7 covers the devicetree binding and
  Frieder Schrempf's Tested-by on 3/7 confirms the driver works on his
  hardware, so neither is a review of the ioctl interface itself.

On using standard kernel interfaces:

- I am not proposing the miscdev as a replacement for existing kernel
  interfaces. Where a standard abstraction already exists, I agree that
  it should be used.

- Fuse/OTP access is already exposed through a standard nvmem provider
  (drivers/nvmem/imx-ocotp-ele.c).

- Some ELE services, such as key sealing/unsealing and random number
  generation, overlap with functionality already available through
  existing kernel frameworks.

- The remaining functionality is the secure-enclave management plane:
  key-store provisioning and reprovision-enable, persistent key-store
  migration, signed OEM container authentication, device attestation,
  and lifecycle transitions. I am not aware of an existing generic
  kernel subsystem that models those operations today.

On what is NXP-specific:

- The cryptographic services exposed through userspace are accessed via
  the PSA APIs provided by imx-smw rather than applications directly
  issuing ELE-specific commands.

- What remains NXP-specific is the secure-enclave management layer:
  provisioning, attestation, lifecycle management, OEM container
  authentication and persistent key-store management. I would rather
  not define a cross-vendor kernel ABI from a single implementation,
  but if there is a plausible shared model across vendors I would be
  happy to work towards that instead.

On passing commands rather than abstracting each operation:

- The ELE firmware ABI is large, versioned, and evolves independently
  of the kernel. Defining a dedicated ioctl for every firmware command
  would effectively freeze those command payloads into the kernel uAPI
  and make firmware ABI evolution a kernel compatibility problem.

- The ioctl is a transport interface rather than a raw firmware escape
  hatch. Commands are validated and constrained by the driver before
  they are forwarded to firmware.

- The stable part is the transport API. The ioctl numbers and
  structures do not change per SoC. Per-MU differences (interface
  type, message tags, base FW version and messaging API version) are
  described by driver data selected from the DT compatible.

- Discovery ioctls allow userspace to determine the SoC and messaging
  API version it is communicating with rather than assuming them. In
  practice, supporting a new MU or SoC is a matter of adding driver
  data and a DT compatible, not changing the uAPI.

On the side-channel concern:

- The kernel's role here is to enforce containment rather than to
  reinterpret each enclave operation.

- Commands are validated before being forwarded. Commands that are not
  explicitly recognised and permitted by the driver are rejected.

- Shared memory is allocated per file descriptor, so one context cannot
  access another context's buffers.

- Userspace never hands firmware an arbitrary pointer. The driver
  allocates and manages the shared buffer and validates all embedded
  addresses against the owning context before transmitting a command.

- Consequently, userspace cannot direct firmware to arbitrary physical
  memory, cannot access another client's buffers, and cannot submit
  unvalidated commands. The interface is constrained and mediated by
  the kernel rather than providing unrestricted firmware access from
  userspace.

Thanks,
Pankaj

NXP Public