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: [email protected]
Reporter: [email protected]
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.
