- 08 Aug, 2014 40 commits
-
-
David Herrmann authored
Some basic tests to verify sealing on memfds works as expected and guarantees the advertised semantics. Signed-off-by:
David Herrmann <dh.herrmann@gmail.com> Acked-by:
Hugh Dickins <hughd@google.com> Cc: Michael Kerrisk <mtk.manpages@gmail.com> Cc: Ryan Lortie <desrt@desrt.ca> Cc: Lennart Poettering <lennart@poettering.net> Cc: Daniel Mack <zonque@gmail.com> Cc: Andy Lutomirski <luto@amacapital.net> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
David Herrmann authored
memfd_create() is similar to mmap(MAP_ANON), but returns a file-descriptor that you can pass to mmap(). It can support sealing and avoids any connection to user-visible mount-points. Thus, it's not subject to quotas on mounted file-systems, but can be used like malloc()'ed memory, but with a file-descriptor to it. memfd_create() returns the raw shmem file, so calls like ftruncate() can be used to modify the underlying inode. Also calls like fstat() will return proper information and mark the file as regular file. If you want sealing, you can specify MFD_ALLOW_SEALING. Otherwise, sealing is not supported (like on all other regular files). Compared to O_TMPFILE, it does not require a tmpfs mount-point and is not subject to a filesystem size limit. It is still properly accounted to memcg limits, though, and to the same overcommit or no-overcommit accounting as all user memory. Signed-off-by:
-
David Herrmann authored
If two processes share a common memory region, they usually want some guarantees to allow safe access. This often includes: - one side cannot overwrite data while the other reads it - one side cannot shrink the buffer while the other accesses it - one side cannot grow the buffer beyond previously set boundaries If there is a trust-relationship between both parties, there is no need for policy enforcement. However, if there's no trust relationship (eg., for general-purpose IPC) sharing memory-regions is highly fragile and often not possible without local copies. Look at the following two use-cases: 1) A graphics client wants to share its rendering-buffer with a graphics-server. The memory-region is allocated by the client for read/write access and a second FD is passed to the server. While scanning out from the memory region, the server has no guarantee that the client doesn't shrink the buffer at any time, requiring rather cumbersome SIGBUS handling. 2) A process wants to perform an RPC on another process. To avoid huge bandwidth consumption, zero-copy is preferred. After a message is assembled in-memory and a FD is passed to the remote side, both sides want to be sure that neither modifies this shared copy, anymore. The source may have put sensible data into the message without a separate copy and the target may want to parse the message inline, to avoid a local copy. While SIGBUS handling, POSIX mandatory locking and MAP_DENYWRITE provide ways to achieve most of this, the first one is unproportionally ugly to use in libraries and the latter two are broken/racy or even disabled due to denial of service attacks. This patch introduces the concept of SEALING. If you seal a file, a specific set of operations is blocked on that file forever. Unlike locks, seals can only be set, never removed. Hence, once you verified a specific set of seals is set, you're guaranteed that no-one can perform the blocked operations on this file, anymore. An initial set of SEALS is introduced by this patch: - SHRINK: If SEAL_SHRINK is set, the file in question cannot be reduced in size. This affects ftruncate() and open(O_TRUNC). - GROW: If SEAL_GROW is set, the file in question cannot be increased in size. This affects ftruncate(), fallocate() and write(). - WRITE: If SEAL_WRITE is set, no write operations (besides resizing) are possible. This affects fallocate(PUNCH_HOLE), mmap() and write(). - SEAL: If SEAL_SEAL is set, no further seals can be added to a file. This basically prevents the F_ADD_SEAL operation on a file and can be set to prevent others from adding further seals that you don't want. The described use-cases can easily use these seals to provide safe use without any trust-relationship: 1) The graphics server can verify that a passed file-descriptor has SEAL_SHRINK set. This allows safe scanout, while the client is allowed to increase buffer size for window-resizing on-the-fly. Concurrent writes are explicitly allowed. 2) For general-purpose IPC, both processes can verify that SEAL_SHRINK, SEAL_GROW and SEAL_WRITE are set. This guarantees that neither process can modify the data while the other side parses it. Furthermore, it guarantees that even with writable FDs passed to the peer, it cannot increase the size to hit memory-limits of the source process (in case the file-storage is accounted to the source). The new API is an extension to fcntl(), adding two new commands: F_GET_SEALS: Return a bitset describing the seals on the file. This can be called on any FD if the underlying file supports sealing. F_ADD_SEALS: Change the seals of a given file. This requires WRITE access to the file and F_SEAL_SEAL may not already be set. Furthermore, the underlying file must support sealing and there may not be any existing shared mapping of that file. Otherwise, EBADF/EPERM is returned. The given seals are _added_ to the existing set of seals on the file. You cannot remove seals again. The fcntl() handler is currently specific to shmem and disabled on all files. A file needs to explicitly support sealing for this interface to work. A separate syscall is added in a follow-up, which creates files that support sealing. There is no intention to support this on other file-systems. Semantics are unclear for non-volatile files and we lack any use-case right now. Therefore, the implementation is specific to shmem. Signed-off-by: -
David Herrmann authored
This patch (of 6): The i_mmap_writable field counts existing writable mappings of an address_space. To allow drivers to prevent new writable mappings, make this counter signed and prevent new writable mappings if it is negative. This is modelled after i_writecount and DENYWRITE. This will be required by the shmem-sealing infrastructure to prevent any new writable mappings after the WRITE seal has been set. In case there exists a writable mapping, this operation will fail with EBUSY. Note that we rely on the fact that iff you already own a writable mapping, you can increase the counter without using the helpers. This is the same that we do for i_writecount. Signed-off-by:
-
Joe Perches authored
A series of commits by Christoph Hellwig removed all the files in this directory, remove the pattern. Signed-off-by:
Joe Perches <joe@perches.com> Cc: Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Joe Perches authored
Commit 87933a68dce6 ("mfd: pm8921: Remove pm8xxx API now that sub-devices use regmap") removed the file, remove the pattern. Signed-off-by:Stephen Boyd <sboyd@codeaurora.org> Signed-off-by:
-
Joe Perches authored
Commit 8dcedd7e87f4 ("UAPI: (Scripted) Disintegrate include/drm") moved the file, remove the pattern. Signed-off-by: -
Joe Perches authored
This never made it into the kernel tree. Remove it. Signed-off-by:
James Hogan <james.hogan@imgtec.com> Signed-off-by:
-
Joe Perches authored
Commit e55f7cd2 ("usb: ohci: remove ep93xx bus glue platform driver") removed the file, remove the section. Signed-off-by:
-
Joe Perches authored
Fix the picoxcell patterns, add the dts directory too. Signed-off-by:
Jamie Iles <jamie@jamieiles.com> Signed-off-by:
-
Joe Perches authored
Use underscore, not dash Signed-off-by:
-
Joe Perches authored
Use dashes not underscores. Signed-off-by:
-
Joe Perches authored
Incorrect pattern used, it's not a directory, it's a file. Fix it. Signed-off-by:
-
Joe Perches authored
Commit 7bf21bc8 ("clk: sirf: re-arch to make the codes support both prima2 and atlas6") moved the files, update the patterns. Signed-off-by:
-
Joe Perches authored
Commit 4171fe2f8a47 ("EFI stub documentation updates") moved the file, update the pattern. Signed-off-by:Roy Franz <roy.franz@linaro.org> Signed-off-by:
-
Joe Perches authored
Commit 30706a54 ("cifs: create a new Documentation/ directory and move docfiles into it") moved the files, update the pattern. Signed-off-by:
-
Joe Perches authored
Commit bad5fa63 ("x86, microcode: Move to a proper location") moved the files, update the pattern. Signed-off-by:
-
Joe Perches authored
Make the code flow a little better for 80 columns. Use a consistent style for the RX and TX rings allocation. Use BIT macro. Use a temporary unsiged int entries for (1<<size). Remove the OOM messages as they duplicate the generic OOM and dump_stack() provided by the memory subsystem. Reflow allocs to 80 columns. Signed-off-by:
Don Fry <pcnet32@frontier.com> Cc: David Miller <davem@davemloft.net> Signed-off-by:
-
Joe Perches authored
Remove the now unnecessary memset too. Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Joe Perches authored
Remove the now unnecessary memset too. Signed-off-by:
-
Joe Perches authored
Remove the now unnecessary memset too. Signed-off-by:
-
Joe Perches authored
Remove the now unnecessary memset too. Signed-off-by:
-
Joe Perches authored
Remove the now unnecessary memset too. Signed-off-by:
-
Joe Perches authored
Remove the now unnecessary memset too. Signed-off-by:
-
Joe Perches authored
Remove the now unnecessary memset too. Signed-off-by:
-
Joe Perches authored
Remove the now unnecessary memset too. Signed-off-by:
-
Joe Perches authored
Remove the now unnecessary memset too. Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Joe Perches authored
Remove the now unnecessary memset too. Signed-off-by:
-
Joe Perches authored
Remove the now unnecessary memset too. Signed-off-by:
-
Joe Perches authored
Remove the now unnecessary memset too. Signed-off-by:
-
Joe Perches authored
Remove the now unnecessary memset too. Signed-off-by:
-
Joe Perches authored
Remove the now unnecessary memset too. Signed-off-by:
-
Joe Perches authored
Remove the now unnecessary memset too. Signed-off-by:
-
Joe Perches authored
Remove the now unnecessary memset too. Signed-off-by:
-
Joe Perches authored
Remove the now unnecessary memset too. Signed-off-by:
-
Joe Perches authored
Remove the now unnecessary memset too. Signed-off-by:
Steve Wise <swise@opengridcomputing.com> Cc: Roland Dreier <roland@kernel.org> Cc: Sean Hefty <sean.hefty@intel.com> Cc: Hal Rosenstock <hal.rosenstock@gmail.com> Cc: Faisal Latif <faisal.latif@intel.com> Signed-off-by:
-
Joe Perches authored
Remove the now unnecessary memset too. Signed-off-by:
-
Joe Perches authored
Remove the now unnecessary memset too. Signed-off-by:
-
Joe Perches authored
Remove the now unnecessary memset too. Signed-off-by:
-
Joe Perches authored
Add this helper for consistency with pci_zalloc_coherent and the ability to remove unnecessary memset(,0,) uses. Signed-off-by:
-
