Versions Compared

Old Version 1

changes.mady.by.user Yuri Pasquali

Saved on

compared with

New Version Current

changes.mady.by.user Yuri Pasquali

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Image Removed

OCDM uses 2 different communication mechanism between Application domain and the DRM platform.

One communication channel is RPC and the other one is Memory Mapped Files (MMF).

The OCDM fork done for RDK uses ordinary files in /tmp (which are the same as shm_open files on Linux).

The paths they use are: /tmp/ocdmbuffer.1 , /tmp/ocdmbuffer.2 , etc up to 7. And /tmp/ocdmbuffer.1.admin , /tmp/ocdmbuffer.2.admin , etc up to 7

All files are owned by root:root by default.

The security/robustness concerns from memfd_create.2.html page is the following: Processes that communicate via shared memory must either trust each other, or take measures to deal with the possibility that an untrusted peer may manipulate the shared memory region in problematic ways. For example, an untrusted peer might modify the contents of the shared memory at any time, or shrink the shared memory region. The former possibility leaves the local process vulnerable to time-of-check-to-time-of-use race conditions (typically dealt with by copying data from the shared memory region before checking and using it). The latter possibility leaves the local process vulnerable to SIGBUS signals when an attempt is made to access a now-nonexistent location in the shared memory region. (Dealing with this possibility necessitates the use of a handler for the SIGBUS signal.)

Dealing with untrusted peers imposes extra complexity on code that employs shared memory. Memory sealing enables that extra complexity to be eliminated, by allowing a process to operate secure in the knowledge that its peer can't modify the shared memory in an undesired fashion.

This is the reason why using memfd_create, apply file sealing and passing the fd to the application using domain sockets is the preferred solution, as shown below:

Code Block
An example of the usage of the sealing mechanism is as follows:

       1. The first process creates a tmpfs(5) file using memfd_create().
          The call yields a file descriptor used in subsequent steps.

       2. The first process sizes the file created in the previous step
          using ftruncate(2), maps it using mmap(2), and populates the
          shared memory with the desired data.

       3. The first process uses the fcntl(2) F_ADD_SEALS operation to place
          one or more seals on the file, in order to restrict further
          modifications on the file.  (If placing the seal F_SEAL_WRITE,
          then it will be necessary to first unmap the shared writable
          mapping created in the previous step.)

       4. A second process obtains a file descriptor for the tmpfs(5) file
          and maps it.  Among the possible ways in which this could happen
          are the following:

          *  The process that called memfd_create() could transfer the
             resulting file descriptor to the second process via a UNIX
             domain socket (see unix(7) and cmsg(3)).  The second process
             then maps the file using mmap(2).

       5. The second process uses the fcntl(2) F_GET_SEALS operation to
          retrieve the bit mask of seals that has been applied to the file.
          This bit mask can be inspected in order to determine what kinds of
          restrictions have been placed on file modifications.  If desired,
          the second process can apply further seals to impose additional
          restrictions (so long as the F_SEAL_SEAL seal has not yet been
          applied).


Possible seals are:
#define F_SEAL_SEAL		0x0001	/* prevent further seals from being set */
#define F_SEAL_SHRINK	0x0002	/* prevent file from shrinking */
#define F_SEAL_GROW		0x0004	/* prevent file from growing */
#define F_SEAL_WRITE	0x0008	/* prevent writes */