[DPDK/ethdev Bug 2017] memif: trust model not documented

[bugzilla@dpdk.org]

https://bugs.dpdk.org/show_bug.cgi?id=2017

            Bug ID: 2017
           Summary: memif: trust model not documented
           Product: DPDK
           Version: 26.11
          Hardware: All
                OS: All
            Status: UNCONFIRMED
          Severity: minor
          Priority: Normal
         Component: ethdev
          Assignee: dev@dpdk.org
          Reporter: stephen@networkplumber.org
  Target Milestone: ---
             Group: security

The AI generated security report raises the observation that memif has an
implicit set of assumptions about trust. These should be made explicit.
The AI generated text for this is.

Since there is no memif specification outside VPP's tree, DPDK should
also state its own normative requirements for a conforming client,
rather than deriving them from whatever VPP happens to do. At minimum:

  - regions are added before the rings that reference them;
  - the file descriptor passed with a region is at least as large as the
    claimed region size;
  - rings are added in order, exactly once;
  - a ring and its descriptor table lie within the region it names, at a
    naturally aligned offset;
  - private_hdr_size is zero;
  - log2_ring_size is no greater than the value the server advertised;
  - descriptor region, offset and length lie within the region they name.

Writing these down is what lets a server reject a non-conforming client
without the rejection being read as a DPDK bug, and gives VPP and
libmemif something to check themselves against.

Add something like this to memif.rst


Security considerations
-----------------------

The trust between the two roles is not symmetric. The client creates the
shared memory and passes the region file descriptors to the server, so
the client trusts the server. The server receives memory it did not
create, from a peer it did not choose.

Where the two ends are in different trust domains, for example either
side of a container boundary, the less trusted end should be configured
as the client.

-- 
You are receiving this mail because:
You are the assignee for the bug.