From: Jeff Xu <jeffxu(a)chromium.org>
Since Linux introduced the memfd feature, memfd have always had their execute bit set, and the memfd_create() syscall doesn't allow setting it differently.
However, in a secure by default system, such as ChromeOS, (where all executables should come from the rootfs, which is protected by Verified boot), this executable nature of memfd opens a door for NoExec bypass and enables “confused deputy attack”. E.g, in VRP bug [1]: cros_vm process created a memfd to share the content with an external process, however the memfd is overwritten and used for executing arbitrary code and root escalation. [2] lists more VRP in this kind.
On the other hand, executable memfd has its legit use, runc uses memfd’s seal and executable feature to copy the contents of the binary then execute them, for such system, we need a solution to differentiate runc's use of executable memfds and an attacker's [3].
To address those above, this set of patches add following:
1> Let memfd_create() set X bit at creation time.
2> Let memfd to be sealed for modifying X bit.
3> A new pid namespace sysctl: vm.memfd_noexec to control behavior of X bit. For example, if a container has vm.memfd_noexec=2, then memfd_create() without MFD_NOEXEC_SEAL will be rejected.
4> A new security hook in memfd_create(). This make it possible to a new LSM, which rejects or allows executable memfd based on its security policy.
This is V4 version of patch: see [4] [5] [6] for previous versions.
[1] https://crbug.com/1305411
[2] https://bugs.chromium.org/p/chromium/issues/list?q=type%3Dbug-security%20me…
[3] https://lwn.net/Articles/781013/
[4] https://lwn.net/Articles/890096/
[5] https://lore.kernel.org/lkml/20220805222126.142525-1-jeffxu@chromium.org/
[6] https://lore.kernel.org/lkml/20221202013404.163143-1-jeffxu@chromium.org/
Daniel Verkamp (2):
mm/memfd: add F_SEAL_EXEC
selftests/memfd: add tests for F_SEAL_EXEC
Jeff Xu (4):
mm/memfd: add MFD_NOEXEC_SEAL and MFD_EXEC
mm/memfd: Add write seals when apply SEAL_EXEC to executable memfd
selftests/memfd: add tests for MFD_NOEXEC_SEAL MFD_EXEC
mm/memfd: security hook for memfd_create
include/linux/lsm_hook_defs.h | 1 +
include/linux/lsm_hooks.h | 4 +
include/linux/pid_namespace.h | 19 ++
include/linux/security.h | 6 +
include/uapi/linux/fcntl.h | 1 +
include/uapi/linux/memfd.h | 4 +
kernel/pid_namespace.c | 48 ++++
mm/memfd.c | 61 ++++-
mm/shmem.c | 6 +
security/security.c | 13 +
tools/testing/selftests/memfd/fuse_test.c | 1 +
tools/testing/selftests/memfd/memfd_test.c | 304 ++++++++++++++++++++-
12 files changed, 465 insertions(+), 3 deletions(-)
base-commit: eb7081409f94a9a8608593d0fb63a1aa3d6f95d8
--
2.39.0.rc0.267.gcb52ba06e7-goog
Today's -next fails to build on arm64 due to:
In file included from include/kvm_util.h:11,
from aarch64/page_fault_test.c:15:
include/ucall_common.h:36:47: note: expected ‘vm_paddr_t’ {aka ‘long unsigned int’} but argument is of type ‘void *’
36 | void ucall_init(struct kvm_vm *vm, vm_paddr_t mmio_gpa);
| ~~~~~~~~~~~^~~~~~~~
aarch64/page_fault_test.c:725:2: warning: implicit declaration of function ‘ucall_uninit’; did you mean ‘ucall_init’? [-Wimplicit-function-declaration]
725 | ucall_uninit(vm);
| ^~~~~~~~~~~~
| ucall_init
which is caused by commit
interacting poorly with commit
28a65567acb5 ("KVM: selftests: Drop now-unnecessary ucall_uninit()")
As is done for other ucall_uninit() users remove the call in the newly added
page_fault_test.c.
Fixes: 28a65567acb5 ("KVM: selftests: Drop now-unnecessary ucall_uninit()")
Fixes: 35c581015712 ("KVM: selftests: aarch64: Add aarch64/page_fault_test")
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Cc: Sean Christopherson <seanjc(a)google.com>
Cc: Ricardo Koller <ricarkol(a)google.com>
Cc: Marc Zyngier <maz(a)kernel.org>
---
tools/testing/selftests/kvm/aarch64/page_fault_test.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/tools/testing/selftests/kvm/aarch64/page_fault_test.c b/tools/testing/selftests/kvm/aarch64/page_fault_test.c
index 05bb6a6369c2..4ef89c57a937 100644
--- a/tools/testing/selftests/kvm/aarch64/page_fault_test.c
+++ b/tools/testing/selftests/kvm/aarch64/page_fault_test.c
@@ -722,7 +722,6 @@ static void run_test(enum vm_guest_mode mode, void *arg)
vcpu_run_loop(vm, vcpu, test);
- ucall_uninit(vm);
kvm_vm_free(vm);
free_uffd(test, pt_uffd, data_uffd);
--
2.30.2
[
This update is primarily collecting remarks from the mailing list, lots of
doc fixes and it is now stably in linux-next without warnings/etc. syzbot
has taken over and is running now, the remaining static tool feedback has
been collected.
s390, Intel x86, ARM and all the VFIO mdevs have been tested now.
]
iommufd is the user API to control the IOMMU subsystem as it relates to
managing IO page tables that point at user space memory.
It takes over from drivers/vfio/vfio_iommu_type1.c (aka the VFIO
container) which is the VFIO specific interface for a similar idea.
We see a broad need for extended features, some being highly IOMMU device
specific:
- Binding iommu_domain's to PASID/SSID
- Userspace IO page tables, for ARM, x86 and S390
- Kernel bypassed invalidation of user page tables
- Re-use of the KVM page table in the IOMMU
- Dirty page tracking in the IOMMU
- Runtime Increase/Decrease of IOPTE size
- PRI support with faults resolved in userspace
Many of these HW features exist to support VM use cases - for instance the
combination of PASID, PRI and Userspace IO Page Tables allows an
implementation of DMA Shared Virtual Addressing (vSVA) within a
guest. Dirty tracking enables VM live migration with SRIOV devices and
PASID support allow creating "scalable IOV" devices, among other things.
As these features are fundamental to a VM platform they need to be
uniformly exposed to all the driver families that do DMA into VMs, which
is currently VFIO and VDPA.
The pre-v1 series proposed re-using the VFIO type 1 data structure,
however it was suggested that if we are doing this big update then we
should also come with an improved data structure that solves the
limitations that VFIO type1 has. Notably this addresses:
- Multiple IOAS/'containers' and multiple domains inside a single FD
- Single-pin operation no matter how many domains and containers use
a page
- A fine grained locking scheme supporting user managed concurrency for
multi-threaded map/unmap
- A pre-registration mechanism to optimize vIOMMU use cases by
pre-pinning pages
- Extended ioctl API that can manage these new objects and exposes
domains directly to user space
- domains are sharable between subsystems, eg VFIO and VDPA
The bulk of this code is a new data structure design to track how the
IOVAs are mapped to PFNs.
iommufd intends to be general and consumable by any driver that wants to
DMA to userspace. From a driver perspective it can largely be dropped in
in-place of iommu_attach_device() and provides a uniform full feature set
to all consumers.
As this is a larger project this series is the first step. This series
provides the iommfd "generic interface" which is designed to be suitable
for applications like DPDK and VMM flows that are not optimized to
specific HW scenarios. It is close to being a drop in replacement for the
existing VFIO type 1 and supports existing qemu based VM flows.
Several follow-on series are being prepared:
- Patches integrating with qemu in native mode:
https://github.com/yiliu1765/qemu/commits/qemu-iommufd-6.0-rc2
- A completed integration with VFIO now exists that covers "emulated" mdev
use cases now, and can pass testing with qemu/etc in compatability mode:
https://github.com/jgunthorpe/linux/commits/vfio_iommufd
- A draft providing system iommu dirty tracking on top of iommufd,
including iommu driver implementations:
https://github.com/jpemartins/linux/commits/x86-iommufd
This pairs with patches for providing a similar API to support VFIO-device
tracking to give a complete vfio solution:
https://lore.kernel.org/kvm/20220901093853.60194-1-yishaih@nvidia.com/
- Userspace page tables aka 'nested translation' for ARM and Intel iommu
drivers:
https://github.com/nicolinc/iommufd/commits/iommufd_nesting
- "device centric" vfio series to expose the vfio_device FD directly as a
normal cdev, and provide an extended API allowing dynamically changing
the IOAS binding:
https://github.com/yiliu1765/iommufd/commits/iommufd-v6.0-rc2-nesting-0901
- Drafts for PASID and PRI interfaces are included above as well
Overall enough work is done now to show the merit of the new API design
and at least draft solutions to many of the main problems.
Several people have contributed directly to this work: Eric Auger, Joao
Martins, Kevin Tian, Lu Baolu, Nicolin Chen, Yi L Liu. Many more have
participated in the discussions that lead here, and provided ideas. Thanks
to all!
The v1/v2 iommufd series has been used to guide a large amount of preparatory
work that has now been merged. The general theme is to organize things in
a way that makes injecting iommufd natural:
- VFIO live migration support with mlx5 and hisi_acc drivers.
These series need a dirty tracking solution to be really usable.
https://lore.kernel.org/kvm/20220224142024.147653-1-yishaih@nvidia.com/https://lore.kernel.org/kvm/20220308184902.2242-1-shameerali.kolothum.thodi…
- Significantly rework the VFIO gvt mdev and remove struct
mdev_parent_ops
https://lore.kernel.org/lkml/20220411141403.86980-1-hch@lst.de/
- Rework how PCIe no-snoop blocking works
https://lore.kernel.org/kvm/0-v3-2cf356649677+a32-intel_no_snoop_jgg@nvidia…
- Consolidate dma ownership into the iommu core code
https://lore.kernel.org/linux-iommu/20220418005000.897664-1-baolu.lu@linux.…
- Make all vfio driver interfaces use struct vfio_device consistently
https://lore.kernel.org/kvm/0-v4-8045e76bf00b+13d-vfio_mdev_no_group_jgg@nv…
- Remove the vfio_group from the kvm/vfio interface
https://lore.kernel.org/kvm/0-v3-f7729924a7ea+25e33-vfio_kvm_no_group_jgg@n…
- Simplify locking in vfio
https://lore.kernel.org/kvm/0-v2-d035a1842d81+1bf-vfio_group_locking_jgg@nv…
- Remove the vfio notifiter scheme that faces drivers
https://lore.kernel.org/kvm/0-v4-681e038e30fd+78-vfio_unmap_notif_jgg@nvidi…
- Improve the driver facing API for vfio pin/unpin pages to make the
presence of struct page clear
https://lore.kernel.org/kvm/20220723020256.30081-1-nicolinc@nvidia.com/
- Clean up in the Intel IOMMU driver
https://lore.kernel.org/linux-iommu/20220301020159.633356-1-baolu.lu@linux.…https://lore.kernel.org/linux-iommu/20220510023407.2759143-1-baolu.lu@linux…https://lore.kernel.org/linux-iommu/20220514014322.2927339-1-baolu.lu@linux…https://lore.kernel.org/linux-iommu/20220706025524.2904370-1-baolu.lu@linux…https://lore.kernel.org/linux-iommu/20220702015610.2849494-1-baolu.lu@linux…
- Rework s390 vfio drivers
https://lore.kernel.org/kvm/20220707135737.720765-1-farman@linux.ibm.com/
- Normalize vfio ioctl handling
https://lore.kernel.org/kvm/0-v2-0f9e632d54fb+d6-vfio_ioctl_split_jgg@nvidi…
- VFIO API for dirty tracking (aka dma logging) managed inside a PCI
device, with mlx5 implementation
https://lore.kernel.org/kvm/20220901093853.60194-1-yishaih@nvidia.com
- Introduce a struct device sysfs presence for struct vfio_device
https://lore.kernel.org/kvm/20220901143747.32858-1-kevin.tian@intel.com/
- Complete restructuring the vfio mdev model
https://lore.kernel.org/kvm/20220822062208.152745-1-hch@lst.de/
- Isolate VFIO container code in preperation for iommufd to provide an
alternative implementation of it all
https://lore.kernel.org/kvm/0-v1-a805b607f1fb+17b-vfio_container_split_jgg@…
- Simplify and consolidate iommu_domain/device compatability checking
https://lore.kernel.org/linux-iommu/cover.1666042872.git.nicolinc@nvidia.co…
- Align iommu SVA support with the domain-centric model
https://lore.kernel.org/all/20221031005917.45690-1-baolu.lu@linux.intel.com/
This is about 233 patches applied since March, thank you to everyone
involved in all this work!
Currently there are a number of supporting series still in progress:
- DMABUF exporter support for VFIO to allow PCI P2P with VFIO
https://lore.kernel.org/r/0-v2-472615b3877e+28f7-vfio_dma_buf_jgg@nvidia.com
- Start to provide iommu_domain ops for POWER
https://lore.kernel.org/all/20220714081822.3717693-1-aik@ozlabs.ru/
However, these are not necessary for this series to advance.
Syzkaller coverage has been merged and is now running in the syzbot
environment on linux-next:
https://github.com/google/syzkaller/pull/3515https://github.com/google/syzkaller/pull/3521
This is on github: https://github.com/jgunthorpe/linux/commits/iommufd
v5:
- Move WARN_ON in __iommu_group_alloc_blocking_domain()
- Fix rebase error of pfn_batch::npfns
- iopt_pages_add/remove_access() is now iopt_area_add/remove_access()
- Change iopt_pages_access::refcount into an unsigned int
- Lower mutex/etc into iopt_area_add_access()
- Match VFIO error codes for some map failure modes
- Block area split if accesses are present
- Match VFIO behavior for pin/unpin when the IOVA is unaligned. Round
down the IOVA to PAGE_SIZE and assume the caller will take an offset
into the first page based on IOVA % PAGE_SIZE
- Increase VFIO_IOMMU_TYPE1_INFO_DMA_AVAIL to U32_MAX for s390
- Enforce that access->ops->unmap is set if pin_pages is used
- Split the test code into several patches to stay below the 100k mailing
list message size limit
- A few code naming changes for clarity
- Use double span for IOVA allocation
- Lots of comment and doc updates
v4: https://lore.kernel.org/r/0-v4-0de2f6c78ed0+9d1-iommufd_jgg@nvidia.com
- Rebase to v6.1-rc3, include the iommu branch with the needed EINVAL
patch series and also the SVA rework
- All bug fixes and comments with no API or behavioral changes
- gvt tests are passing again
- Syzkaller is no longer finding issues and achieved high coverage of
69%(75%)
- Coverity has been run by two people
- new "nth failure" test that systematically sweeps all error unwind paths
looking for splats
- All fixes noted in the mailing list
If you sent an email and I didn't reply please ping it, I have lost it.
- The selftest patch has been broken into three to make the additional
modification to the main code clearer
- The interdiff is 1.8k lines for the main code, with another 3k of
test suite changes
v3: https://lore.kernel.org/r/0-v3-402a7d6459de+24b-iommufd_jgg@nvidia.com
- Rebase to v6.1-rc1
- Improve documentation
- Use EXPORT_SYMBOL_NS
- Fix W1, checkpatch stuff
- Revise pages.c to resolve the FIXMEs. Create a
interval_tree_double_span_iter which allows a simple expression of the
previously problematic algorithms
- Consistently use the word 'access' instead of user to refer to an
access from an in-kernel user (eg vfio mdev)
- Support two forms of rlimit accounting and make the vfio compatible one
the default in compatability mode (following series)
- Support old VFIO type1 by disabling huge pages and implementing a
simple algorithm to split a struct iopt_area
- Full implementation of access support, test coverage and optimizations
- Complete COPY to be able to copy across contiguous areas. Improve
all the algorithms around contiguous areas with a dedicated iterator
- Functional ENFORCED_COHERENT support
- Support multi-device groups
- Lots of smaller changes (the interdiff is 5k lines)
v2: https://lore.kernel.org/r/0-v2-f9436d0bde78+4bb-iommufd_jgg@nvidia.com
- Rebase to v6.0-rc3
- Improve comments
- Change to an iterative destruction approach to avoid cycles
- Near rewrite of the vfio facing implementation, supported by a complete
implementation on the vfio side
- New IOMMU_IOAS_ALLOW_IOVAS API as discussed. Allows userspace to
assert that ranges of IOVA must always be mappable. To be used by a VMM
that has promised a guest a certain availability of IOVA. May help
guide PPC's multi-window implementation.
- Rework how unmap_iova works, user can unmap the whole ioas now
- The no-snoop / wbinvd support is implemented
- Bug fixes
- Test suite improvements
- Lots of smaller changes (the interdiff is 3k lines)
v1: https://lore.kernel.org/r/0-v1-e79cd8d168e8+6-iommufd_jgg@nvidia.com
# S390 in-kernel page table walker
Cc: Niklas Schnelle <schnelle(a)linux.ibm.com>
Cc: Matthew Rosato <mjrosato(a)linux.ibm.com>
# AMD Dirty page tracking
Cc: Joao Martins <joao.m.martins(a)oracle.com>
# ARM SMMU Dirty page tracking
Cc: Keqian Zhu <zhukeqian1(a)huawei.com>
Cc: Shameerali Kolothum Thodi <shameerali.kolothum.thodi(a)huawei.com>
# ARM SMMU nesting
Cc: Eric Auger <eric.auger(a)redhat.com>
Cc: Jean-Philippe Brucker <jean-philippe(a)linaro.org>
# Map/unmap performance
Cc: Daniel Jordan <daniel.m.jordan(a)oracle.com>
# VDPA
Cc: "Michael S. Tsirkin" <mst(a)redhat.com>
Cc: Jason Wang <jasowang(a)redhat.com>
# Power
Cc: David Gibson <david(a)gibson.dropbear.id.au>
# vfio
Cc: Alex Williamson <alex.williamson(a)redhat.com>
Cc: Cornelia Huck <cohuck(a)redhat.com>
Cc: kvm(a)vger.kernel.org
# iommu
Cc: iommu(a)lists.linux.dev
# Collaborators
Cc: "Chaitanya Kulkarni" <chaitanyak(a)nvidia.com>
Cc: Nicolin Chen <nicolinc(a)nvidia.com>
Cc: Lu Baolu <baolu.lu(a)linux.intel.com>
Cc: Kevin Tian <kevin.tian(a)intel.com>
Cc: Yi Liu <yi.l.liu(a)intel.com>
# s390
Cc: Eric Farman <farman(a)linux.ibm.com>
Cc: Anthony Krowiak <akrowiak(a)linux.ibm.com>
Cc: Halil Pasic <pasic(a)linux.ibm.com>
Cc: Jason Herne <jjherne(a)linux.ibm.com>
Signed-off-by: Jason Gunthorpe <jgg(a)nvidia.com>
Jason Gunthorpe (17):
iommu: Add IOMMU_CAP_ENFORCE_CACHE_COHERENCY
interval-tree: Add a utility to iterate over spans in an interval tree
scripts/kernel-doc: support EXPORT_SYMBOL_NS_GPL() with -export
iommufd: File descriptor, context, kconfig and makefiles
kernel/user: Allow user::locked_vm to be usable for iommufd
iommufd: PFN handling for iopt_pages
iommufd: Algorithms for PFN storage
iommufd: Data structure to provide IOVA to PFN mapping
iommufd: IOCTLs for the io_pagetable
iommufd: Add a HW pagetable object
iommufd: Add kAPI toward external drivers for physical devices
iommufd: Add kAPI toward external drivers for kernel access
iommufd: vfio container FD ioctl compatibility
iommufd: Add kernel support for testing iommufd
iommufd: Add some fault injection points
iommufd: Add additional invariant assertions
iommufd: Add a selftest
Kevin Tian (1):
iommufd: Document overview of iommufd
Lu Baolu (1):
iommu: Add device-centric DMA ownership interfaces
.clang-format | 3 +
Documentation/userspace-api/index.rst | 1 +
.../userspace-api/ioctl/ioctl-number.rst | 1 +
Documentation/userspace-api/iommufd.rst | 223 ++
MAINTAINERS | 12 +
drivers/iommu/Kconfig | 1 +
drivers/iommu/Makefile | 2 +-
drivers/iommu/amd/iommu.c | 2 +
drivers/iommu/intel/iommu.c | 16 +-
drivers/iommu/iommu.c | 121 +-
drivers/iommu/iommufd/Kconfig | 23 +
drivers/iommu/iommufd/Makefile | 13 +
drivers/iommu/iommufd/device.c | 774 +++++++
drivers/iommu/iommufd/double_span.h | 53 +
drivers/iommu/iommufd/hw_pagetable.c | 57 +
drivers/iommu/iommufd/io_pagetable.c | 1212 ++++++++++
drivers/iommu/iommufd/io_pagetable.h | 241 ++
drivers/iommu/iommufd/ioas.c | 390 ++++
drivers/iommu/iommufd/iommufd_private.h | 307 +++
drivers/iommu/iommufd/iommufd_test.h | 93 +
drivers/iommu/iommufd/main.c | 419 ++++
drivers/iommu/iommufd/pages.c | 1981 +++++++++++++++++
drivers/iommu/iommufd/selftest.c | 853 +++++++
drivers/iommu/iommufd/vfio_compat.c | 458 ++++
include/linux/interval_tree.h | 58 +
include/linux/iommu.h | 17 +
include/linux/iommufd.h | 102 +
include/linux/sched/user.h | 2 +-
include/uapi/linux/iommufd.h | 335 +++
kernel/user.c | 1 +
lib/Kconfig | 4 +
lib/interval_tree.c | 132 ++
scripts/kernel-doc | 12 +-
tools/testing/selftests/Makefile | 1 +
tools/testing/selftests/iommu/.gitignore | 3 +
tools/testing/selftests/iommu/Makefile | 12 +
tools/testing/selftests/iommu/config | 2 +
tools/testing/selftests/iommu/iommufd.c | 1627 ++++++++++++++
.../selftests/iommu/iommufd_fail_nth.c | 580 +++++
tools/testing/selftests/iommu/iommufd_utils.h | 278 +++
40 files changed, 10385 insertions(+), 37 deletions(-)
create mode 100644 Documentation/userspace-api/iommufd.rst
create mode 100644 drivers/iommu/iommufd/Kconfig
create mode 100644 drivers/iommu/iommufd/Makefile
create mode 100644 drivers/iommu/iommufd/device.c
create mode 100644 drivers/iommu/iommufd/double_span.h
create mode 100644 drivers/iommu/iommufd/hw_pagetable.c
create mode 100644 drivers/iommu/iommufd/io_pagetable.c
create mode 100644 drivers/iommu/iommufd/io_pagetable.h
create mode 100644 drivers/iommu/iommufd/ioas.c
create mode 100644 drivers/iommu/iommufd/iommufd_private.h
create mode 100644 drivers/iommu/iommufd/iommufd_test.h
create mode 100644 drivers/iommu/iommufd/main.c
create mode 100644 drivers/iommu/iommufd/pages.c
create mode 100644 drivers/iommu/iommufd/selftest.c
create mode 100644 drivers/iommu/iommufd/vfio_compat.c
create mode 100644 include/linux/iommufd.h
create mode 100644 include/uapi/linux/iommufd.h
create mode 100644 tools/testing/selftests/iommu/.gitignore
create mode 100644 tools/testing/selftests/iommu/Makefile
create mode 100644 tools/testing/selftests/iommu/config
create mode 100644 tools/testing/selftests/iommu/iommufd.c
create mode 100644 tools/testing/selftests/iommu/iommufd_fail_nth.c
create mode 100644 tools/testing/selftests/iommu/iommufd_utils.h
base-commit: 69e61edebea030f177de7a23b8d5d9b8c4a90bda
--
2.38.1
From: Jeff Xu <jeffxu(a)chromium.org>
Since Linux introduced the memfd feature, memfd have always had their execute bit set, and the memfd_create() syscall doesn't allow setting it differently.
However, in a secure by default system, such as ChromeOS, (where all executables should come from the rootfs, which is protected by Verified boot), this executable nature of memfd opens a door for NoExec bypass and enables “confused deputy attack”. E.g, in VRP bug [1]: cros_vm process created a memfd to share the content with an external process, however the memfd is overwritten and used for executing arbitrary code and root escalation. [2] lists more VRP in this kind.
On the other hand, executable memfd has its legit use, runc uses memfd’s seal and executable feature to copy the contents of the binary then execute them, for such system, we need a solution to differentiate runc's use of executable memfds and an attacker's [3].
To address those above, this set of patches add following:
1> Let memfd_create() set X bit at creation time.
2> Let memfd to be sealed for modifying X bit.
3> A new pid namespace sysctl: vm.memfd_noexec to control behavior of X bit. For example, if a container has vm.memfd_noexec=2, then memfd_create() without MFD_NOEXEC_SEAL will be rejected.
4> A new security hook in memfd_create(). This make it possible to a new LSM, which rejects or allows executable memfd based on its security policy.
This is V4 version of patch: see [4] [5] [6] for previous versions.
[1] https://crbug.com/1305411
[2] https://bugs.chromium.org/p/chromium/issues/list?q=type%3Dbug-security%20me…
[3] https://lwn.net/Articles/781013/
[4] https://lwn.net/Articles/890096/
[5] https://lore.kernel.org/lkml/20220805222126.142525-1-jeffxu@chromium.org/
[6] https://lore.kernel.org/lkml/20221202013404.163143-1-jeffxu@chromium.org/
Daniel Verkamp (2):
mm/memfd: add F_SEAL_EXEC
selftests/memfd: add tests for F_SEAL_EXEC
Jeff Xu (4):
mm/memfd: add MFD_NOEXEC_SEAL and MFD_EXEC
mm/memfd: Add write seals when apply SEAL_EXEC to executable memfd
selftests/memfd: add tests for MFD_NOEXEC_SEAL MFD_EXEC
mm/memfd: security hook for memfd_create
include/linux/lsm_hook_defs.h | 1 +
include/linux/lsm_hooks.h | 4 +
include/linux/pid_namespace.h | 19 ++
include/linux/security.h | 6 +
include/uapi/linux/fcntl.h | 1 +
include/uapi/linux/memfd.h | 4 +
kernel/pid_namespace.c | 48 ++++
mm/memfd.c | 61 ++++-
mm/shmem.c | 6 +
security/security.c | 13 +
tools/testing/selftests/memfd/fuse_test.c | 1 +
tools/testing/selftests/memfd/memfd_test.c | 304 ++++++++++++++++++++-
12 files changed, 465 insertions(+), 3 deletions(-)
base-commit: eb7081409f94a9a8608593d0fb63a1aa3d6f95d8
--
2.39.0.rc0.267.gcb52ba06e7-goog
Currently in order to test a static function, tests must be included in the
same translation unit as the function. However, this can cause issues with
including implementation and test code in the same file. As an alternative,
the first patch in this series creates a macro that will set a function to
be static or not depending on whether CONFIG_KUNIT is enabled. This allows
the function to be visible during testing and static otherwise.
As an example, the current status quo to test static functions is:
=== test.c ===
static void test_case(struct kunit *test)
{
KUNIT_EXPECT_EQ(test, my_func_to_test(), 2);
}
Then the tests are included in the implementation file as a workaround to
the issue of testing static functions:
=== implementation.c ===
static int my_func_to_test() {...}
...
#include "test.c"
Instead, the function could be defined with this new macro:
=== implementation.c ===
VISIBLE_IF_KUNIT int my_func_to_test() {...}
The first patch also creates a macro that will export a symbol into a kunit
testing namespace only if CONFIG_KUNIT is enabled. This follows the logic
above and allows symbols to be conditionally exported based on the testing
status.
The second patch in the series updates the policy_unpack test in AppArmor
to show an example of how to use both of these macros in order to address
the issue of testing static functions.
Thanks!
-Rae
Changes since v1:
- Changed the namespace of exported symbols for the apparmor
policy_unpack_test by adding the aa_ prefix.
- Separated the documentation comments for macros in
include/kunit/visibility.h.
- Changed copyright date and author for include/kunit/visibility.h.
Rae Moar (2):
kunit: add macro to allow conditionally exposing static symbols to
tests
apparmor: test: make static symbols visible during kunit testing
include/kunit/visibility.h | 33 +++
security/apparmor/Kconfig | 4 +-
security/apparmor/Makefile | 2 +
security/apparmor/include/policy_unpack.h | 50 +++++
security/apparmor/policy_unpack.c | 238 ++++++++++------------
security/apparmor/policy_unpack_test.c | 69 ++++---
6 files changed, 228 insertions(+), 168 deletions(-)
create mode 100644 include/kunit/visibility.h
base-commit: 0f08f3e2a0186dfb8e33cb46105228eb18448a0e
--
2.39.0.rc0.267.gcb52ba06e7-goog
I finally had the time to run some of the selftests written by me
(especially "cow") on x86 PAE. I found some unexpected "surprises" :)
With these changes, and with [1] on top of mm-unstable, the "cow" tests and
the "ksm_functional_tests" compile and pass as expected (expected failures
with hugetlb in the "cow" tests). "madv_populate" has one expected test
failure -- x86 does not support softdirty tracking.
#1-#3 fix commits with stable commit ids. #4 fixes a test that is not in
mm-stable yet.
A note that there are many other compile errors/warnings when compiling
on 32bit and with older Linux headers ... something for another day.
[1] https://lkml.kernel.org/r/20221205150857.167583-1-david@redhat.com
Cc: Andrew Morton <akpm(a)linux-foundation.org>
Cc: Shuah Khan <shuah(a)kernel.org>
Cc: Yang Li <yang.lee(a)linux.alibaba.com>
David Hildenbrand (4):
mm/gup_test: fix PIN_LONGTERM_TEST_READ with highmem
selftests/vm: madv_populate: fix missing MADV_POPULATE_(READ|WRITE)
definitions
selftests/vm: cow: fix compile warning on 32bit
selftests/vm: ksm_functional_tests: fixes for 32bit
mm/gup_test.c | 10 +++++++---
tools/testing/selftests/vm/cow.c | 4 ++--
tools/testing/selftests/vm/ksm_functional_tests.c | 4 ++--
tools/testing/selftests/vm/madv_populate.c | 7 +++++++
tools/testing/selftests/vm/vm_util.c | 2 +-
5 files changed, 19 insertions(+), 8 deletions(-)
--
2.38.1
