The default file permissions on a memfd include execute bits, which
means that such a memfd can be filled with a executable and passed to
the exec() family of functions. This is undesirable on systems where all
code is verified and all filesystems are intended to be mounted noexec,
since an attacker may be able to use a memfd to load unverified code and
execute it.
Additionally, execution via memfd is a common way to avoid scrutiny for
malicious code, since it allows execution of a program without a file
ever appearing on disk. This attack vector is not totally mitigated with
this new flag, since the default memfd file permissions must remain
executable to avoid breaking existing legitimate uses, but it should be
possible to use other security mechanisms to prevent memfd_create calls
without MFD_NOEXEC on systems where it is known that executable memfds
are not necessary.
This patch series adds a new MFD_NOEXEC flag for memfd_create(), which
allows creation of non-executable memfds, and as part of the
implementation of this new flag, it also adds a new F_SEAL_EXEC seal,
which will prevent modification of any of the execute bits of a sealed
memfd.
I am not sure if this is the best way to implement the desired behavior
(for example, the F_SEAL_EXEC seal is really more of an implementation
detail and feels a bit clunky to expose), so suggestions are welcome
for alternate approaches.
Daniel Verkamp (4):
mm/memfd: add F_SEAL_EXEC
mm/memfd: add MFD_NOEXEC flag to memfd_create
selftests/memfd: add tests for F_SEAL_EXEC
selftests/memfd: add tests for MFD_NOEXEC
include/uapi/linux/fcntl.h | 1 +
include/uapi/linux/memfd.h | 1 +
mm/memfd.c | 12 ++-
mm/shmem.c | 6 ++
tools/testing/selftests/memfd/memfd_test.c | 114 +++++++++++++++++++++
5 files changed, 133 insertions(+), 1 deletion(-)
--
2.35.1.1094.g7c7d902a7c-goog
This v2 series implements selftests targeting the feature floated by Chao
via:
https://lore.kernel.org/linux-mm/20220310140911.50924-1-chao.p.peng@linux.i…
Below changes aim to test the fd based approach for guest private memory
in context of normal (non-confidential) VMs executing on non-confidential
platforms.
priv_memfd_test.c file adds a suite of selftests to access private memory
from the guest via private/shared accesses and checking if the contents
can be leaked to/accessed by vmm via shared memory view.
Updates in V2:
1) Tests are added to exercise implicit/explicit memory conversion paths.
2) Test is added to exercise UPM feature without double memory allocation.
This series has dependency on following patches:
1) V5 series patches from Chao mentioned above.
2) https://github.com/vishals4gh/linux/commit/b9adedf777ad84af39042e9c19899600…
- Fixes host kernel crash with current implementation
3) https://github.com/vishals4gh/linux/commit/0577e351ee36d52c1f6cdcb1b8de7aa6…
- Confidential platforms along with the confidentiality aware software stack
support a notion of private/shared accesses from the confidential VMs.
Generally, a bit in the GPA conveys the shared/private-ness of the access.
Non-confidential platforms don't have a notion of private or shared accesses
from the guest VMs. To support this notion, KVM_HC_MAP_GPA_RANGE is modified
to allow marking an access from a VM within a GPA range as always shared or
private. There is an ongoing discussion about adding support for
software-only confidential VMs, which should replace this patch.
4) https://github.com/vishals4gh/linux/commit/8d46aea9a7d72e4b1b998066ce0dde08…
- Temporary placeholder to be able to test memory conversion paths
till the memory conversion exit error code is finalized.
5) https://github.com/vishals4gh/linux/commit/4c36706477c62d9416d635fa6ac4ef64…
- Fixes GFN calculation during memory conversion path.
Github link for the patches posted as part of this series:
https://github.com/vishals4gh/linux/commits/priv_memfd_selftests_rfc_v2
Austin Diviness (1):
selftests: kvm: Add hugepage support to priv_memfd_test suite.
Vishal Annapurve (7):
selftests: kvm: Fix inline assembly for hypercall
selftests: kvm: Add a basic selftest to test private memory
selftests: kvm: priv_memfd_test: Add support for memory conversion
selftests: kvm: priv_memfd_test: Add shared access test
selftests: kvm: Add implicit memory conversion tests
selftests: kvm: Add KVM_HC_MAP_GPA_RANGE hypercall test
selftests: kvm: priv_memfd: Add test avoiding double allocation
tools/testing/selftests/kvm/Makefile | 1 +
.../selftests/kvm/lib/x86_64/processor.c | 2 +-
tools/testing/selftests/kvm/priv_memfd_test.c | 1359 +++++++++++++++++
3 files changed, 1361 insertions(+), 1 deletion(-)
create mode 100644 tools/testing/selftests/kvm/priv_memfd_test.c
--
2.36.0.512.ge40c2bad7a-goog
Add a new QEMU config for kunit_tool, x86_64-smp, which provides an
8-cpu SMP setup. No other kunit_tool configurations provide an SMP
setup, so this is the best bet for testing things like KCSAN, which
require a multicore/multi-cpu system.
The choice of 8 CPUs is pretty arbitrary: it's enough to get tests like
KCSAN to run with a nontrivial number of worker threads, while still
working relatively quickly on older machines.
Signed-off-by: David Gow <davidgow(a)google.com>
---
This is based off the discussion in:
https://groups.google.com/g/kasan-dev/c/A7XzC2pXRC8
---
tools/testing/kunit/qemu_configs/x86_64-smp.py | 13 +++++++++++++
1 file changed, 13 insertions(+)
create mode 100644 tools/testing/kunit/qemu_configs/x86_64-smp.py
diff --git a/tools/testing/kunit/qemu_configs/x86_64-smp.py b/tools/testing/kunit/qemu_configs/x86_64-smp.py
new file mode 100644
index 000000000000..a95623f5f8b7
--- /dev/null
+++ b/tools/testing/kunit/qemu_configs/x86_64-smp.py
@@ -0,0 +1,13 @@
+# SPDX-License-Identifier: GPL-2.0
+from ..qemu_config import QemuArchParams
+
+QEMU_ARCH = QemuArchParams(linux_arch='x86_64',
+ kconfig='''
+CONFIG_SERIAL_8250=y
+CONFIG_SERIAL_8250_CONSOLE=y
+CONFIG_SMP=y
+ ''',
+ qemu_arch='x86_64',
+ kernel_path='arch/x86/boot/bzImage',
+ kernel_command_line='console=ttyS0',
+ extra_qemu_params=['-smp', '8'])
--
2.36.0.550.gb090851708-goog
This patch set extends the locked port feature for devices
that are behind a locked port, but do not have the ability to
authorize themselves as a supplicant using IEEE 802.1X.
Such devices can be printers, meters or anything related to
fixed installations. Instead of 802.1X authorization, devices
can get access based on their MAC addresses being whitelisted.
For an authorization daemon to detect that a device is trying
to get access through a locked port, the bridge will add the
MAC address of the device to the FDB with a locked flag to it.
Thus the authorization daemon can catch the FDB add event and
check if the MAC address is in the whitelist and if so replace
the FDB entry without the locked flag enabled, and thus open
the port for the device.
This feature is known as MAC-Auth or MAC Authentication Bypass
(MAB) in Cisco terminology, where the full MAB concept involves
additional Cisco infrastructure for authorization. There is no
real authentication process, as the MAC address of the device
is the only input the authorization daemon, in the general
case, has to base the decision if to unlock the port or not.
With this patch set, an implementation of the offloaded case is
supplied for the mv88e6xxx driver. When a packet ingresses on
a locked port, an ATU miss violation event will occur. When
handling such ATU miss violation interrupts, the MAC address of
the device is added to the FDB with a zero destination port
vector (DPV) and the MAC address is communicated through the
switchdev layer to the bridge, so that a FDB entry with the
locked flag enabled can be added.
Hans Schultz (4):
net: bridge: add fdb flag to extent locked port feature
net: switchdev: add support for offloading of fdb locked flag
net: dsa: mv88e6xxx: mac-auth/MAB implementation
selftests: forwarding: add test of MAC-Auth Bypass to locked port
tests
drivers/net/dsa/mv88e6xxx/Makefile | 1 +
drivers/net/dsa/mv88e6xxx/chip.c | 40 ++-
drivers/net/dsa/mv88e6xxx/chip.h | 5 +
drivers/net/dsa/mv88e6xxx/global1.h | 1 +
drivers/net/dsa/mv88e6xxx/global1_atu.c | 35 ++-
.../net/dsa/mv88e6xxx/mv88e6xxx_switchdev.c | 249 ++++++++++++++++++
.../net/dsa/mv88e6xxx/mv88e6xxx_switchdev.h | 40 +++
drivers/net/dsa/mv88e6xxx/port.c | 32 ++-
drivers/net/dsa/mv88e6xxx/port.h | 2 +
include/net/dsa.h | 6 +
include/net/switchdev.h | 3 +-
include/uapi/linux/neighbour.h | 1 +
net/bridge/br.c | 3 +-
net/bridge/br_fdb.c | 18 +-
net/bridge/br_if.c | 1 +
net/bridge/br_input.c | 11 +-
net/bridge/br_private.h | 9 +-
.../net/forwarding/bridge_locked_port.sh | 42 ++-
18 files changed, 470 insertions(+), 29 deletions(-)
create mode 100644 drivers/net/dsa/mv88e6xxx/mv88e6xxx_switchdev.c
create mode 100644 drivers/net/dsa/mv88e6xxx/mv88e6xxx_switchdev.h
--
2.30.2
Note: this series applies on top of
https://lore.kernel.org/linux-kselftest/20220516194730.1546328-2-dlatypov@g….
That patch greatly simplified the process of adding new flags.
This flag would let users pass additional arguments to QEMU when using a
non-UML arch to run their tests.
E.g. for kcsan's tests, they require SMP and with this patch, you can do
$ ./tools/testing/kunit/kunit.py run --kconfig_add=CONFIG_SMP --qemu_args='-smp 8'
This is proposed as an alternative to users manually creating new
qemu_config python files and also to [1], where we discussed checking in
a new x86_64 variant w/ `-smp 8` hard-coded into it.
This patch also contains a fix to the example `run_kunit` bash function
since it didn't quote properly and would parse the example above as
--qemu_args='-smp' '8'
no matter how you tried to quote your arguments.
[1] https://lore.kernel.org/linux-kselftest/20220518073232.526443-1-davidgow@go…
Daniel Latypov (3):
Documentation: kunit: fix example run_kunit func to allow spaces in
args
kunit: tool: simplify creating LinuxSourceTreeOperations
kunit: tool: introduce --qemu_args
.../dev-tools/kunit/running_tips.rst | 2 +-
tools/testing/kunit/kunit.py | 14 +++++++++-
tools/testing/kunit/kunit_kernel.py | 26 +++++++++++--------
tools/testing/kunit/kunit_tool_test.py | 20 +++++++++++---
4 files changed, 46 insertions(+), 16 deletions(-)
--
2.36.1.124.g0e6072fb45-goog
Context:
When using a non-UML arch, kunit.py will boot the test kernel with
options like these by default (this is x86_64):
> mem=1G console=tty kunit_shutdown=halt console=ttyS0 kunit_shutdown=reboot
The first three options are added unconditionally but are only intended
for UML.
1. 'mem=1G' is redundant with the '-m 1024' that we hard-code into the
qemu commandline.
2. We specify a 'console' for all tools/testing/kunit/qemu_configs/*.py
already, so 'console=tty' gets overwritten.
3. For QEMU, we need to use 'reboot', and for UML we need to use 'halt'.
If you switch them, kunit.py will hang until the --timeout expires.
This patch:
Having these duplicate options is a bit noisy.
Switch so we only add UML-specific options for UML.
I.e. we now get
UML: 'mem=1G console=tty kunit_shutdown=halt' (unchanged)
x86_64: 'console=ttyS0 kunit_shutdown=reboot'
Side effect: you can't overwrite these options on UML w/ --kernel_arg.
But you already couldn't for QEMU (console, kunit_shutdown), and why
would you want to?
Signed-off-by: Daniel Latypov <dlatypov(a)google.com>
Reviewed-by: David Gow <davidgow(a)google.com>
---
v1 -> v2: Remove other UML-specific args from other arches.
I.e. also only specify "mem=1G and console=tty" for UML.
---
tools/testing/kunit/kunit_kernel.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/kunit/kunit_kernel.py b/tools/testing/kunit/kunit_kernel.py
index 1b9c4922a675..8945640b5063 100644
--- a/tools/testing/kunit/kunit_kernel.py
+++ b/tools/testing/kunit/kunit_kernel.py
@@ -160,6 +160,7 @@ class LinuxSourceTreeOperationsUml(LinuxSourceTreeOperations):
def start(self, params: List[str], build_dir: str) -> subprocess.Popen:
"""Runs the Linux UML binary. Must be named 'linux'."""
linux_bin = os.path.join(build_dir, 'linux')
+ params.extend(['mem=1G', 'console=tty', 'kunit_shutdown=halt'])
return subprocess.Popen([linux_bin] + params,
stdin=subprocess.PIPE,
stdout=subprocess.PIPE,
@@ -334,7 +335,6 @@ class LinuxSourceTree(object):
def run_kernel(self, args=None, build_dir='', filter_glob='', timeout=None) -> Iterator[str]:
if not args:
args = []
- args.extend(['mem=1G', 'console=tty', 'kunit_shutdown=halt'])
if filter_glob:
args.append('kunit.filter_glob='+filter_glob)
base-commit: 9660209d9418f2295d31fea0d32e313e9b2c1200
--
2.36.0.550.gb090851708-goog
It's always set to true except in one test case.
And in that test case it can safely be set to true anyways.
Signed-off-by: Daniel Latypov <dlatypov(a)google.com>
---
tools/testing/kunit/kunit_kernel.py | 4 ----
tools/testing/kunit/kunit_tool_test.py | 2 +-
2 files changed, 1 insertion(+), 5 deletions(-)
diff --git a/tools/testing/kunit/kunit_kernel.py b/tools/testing/kunit/kunit_kernel.py
index 3539efaf99ba..8bc8305ba817 100644
--- a/tools/testing/kunit/kunit_kernel.py
+++ b/tools/testing/kunit/kunit_kernel.py
@@ -219,7 +219,6 @@ class LinuxSourceTree:
def __init__(
self,
build_dir: str,
- load_config=True,
kunitconfig_path='',
kconfig_add: Optional[List[str]]=None,
arch=None,
@@ -233,9 +232,6 @@ class LinuxSourceTree:
self._arch = 'um' if arch is None else arch
self._ops = get_source_tree_ops(self._arch, cross_compile)
- if not load_config:
- return
-
if kunitconfig_path:
if os.path.isdir(kunitconfig_path):
kunitconfig_path = os.path.join(kunitconfig_path, KUNITCONFIG_PATH)
diff --git a/tools/testing/kunit/kunit_tool_test.py b/tools/testing/kunit/kunit_tool_test.py
index 25a2eb3bf114..b9158017ece6 100755
--- a/tools/testing/kunit/kunit_tool_test.py
+++ b/tools/testing/kunit/kunit_tool_test.py
@@ -393,7 +393,7 @@ class LinuxSourceTreeTest(unittest.TestCase):
return subprocess.Popen(['echo "hi\nbye"'], shell=True, text=True, stdout=subprocess.PIPE)
with tempfile.TemporaryDirectory('') as build_dir:
- tree = kunit_kernel.LinuxSourceTree(build_dir, load_config=False)
+ tree = kunit_kernel.LinuxSourceTree(build_dir)
mock.patch.object(tree._ops, 'start', side_effect=fake_start).start()
with self.assertRaises(ValueError):
base-commit: 8a7ccad38f8b25c8202efd69371a022357286400
--
2.36.1.124.g0e6072fb45-goog