Re: [PATCH v2] Input: xen-kbdfront - bound the backend-supplied keycode

[Guo Zihao <guozh23@xiaopeng.com>]

Hi Dmitry,

The threat model is a compromised backend: the xenbus device model gives
the backend write access to the shared ring page for the entire lifetime
of the frontend, and the guest has no way to distinguish well-formed
input from forged input once the peer on the other end is malicious.

Two scenarios where that peer is not fully trusted:

- Multi-tenant hosts. The backend lives in dom0, so a kernel compromise
  of the host should not immediately translate into kernel memory
  corruption inside the guests. Frontends are the last line of defence
  there: every frontend that consumes ring data without validation hands
  the attacker a structured memory-corruption primitive in the guest,
  which is a meaningful step beyond "the host can already do anything".

- Driver domain disaggregation. Backends can also run in unprivileged
  driver domains, where compromising the backend is much cheaper than
  compromising dom0.

This is the same model under which mainline keeps accepting frontend
hardening, for example:

  9b4cf60c6b73 ("9p/xen: validate the response size from the backend")
  d33846c8dcc0 ("xen/pvcalls: bound backend response req_id before indexing rsp[]")
  992df081bc88 ("xen/scsifront: check for a NULL shadow entry on a backend response")
  808e530654a5 ("misc: nsm: bound the device-reported response length")
  e3046eeada29 ("hwrng: virtio: clamp device-reported used.len at copy_data()")

and the READ_ONCE() snapshot in v2 follows the same convention as
8135cf8b0927 ("xen/pciback: Save xen_pci_op commands before processing it").

The keycode here is the kbdfront instance of that pattern: a plain u32
read from the shared page and used as a bitmap index, with nothing
between the fetch and the use.

Thanks,
Guo Zihao