April 2022 - Linux-kselftest-mirror

[PATCH 1/2] userfaultfd: add /dev/userfaultfd for fine grained access control

by Axel Rasmussen

Historically, it has been shown that intercepting kernel faults with userfaultfd (thereby forcing the kernel to wait for an arbitrary amount of time) can be exploited, or at least can make some kinds of exploits easier. So, in 37cd0575b8 "userfaultfd: add UFFD_USER_MODE_ONLY" we changed things so, in order for kernel faults to be handled by userfaultfd, either the process needs CAP_SYS_PTRACE, or this sysctl must be configured so that any unprivileged user can do it. In a typical implementation of a hypervisor with live migration (take QEMU/KVM as one such example), we do indeed need to be able to handle kernel faults. But, both options above are less than ideal: - Toggling the sysctl increases attack surface by allowing any unprivileged user to do it. - Granting the live migration process CAP_SYS_PTRACE gives it this ability, but *also* the ability to "observe and control the execution of another process [...], and examine and change [its] memory and registers" (from ptrace(2)). This isn't something we need or want to be able to do, so granting this permission violates the "principle of least privilege". This is all a long winded way to say: we want a more fine-grained way to grant access to userfaultfd, without granting other additional permissions at the same time. To achieve this, add a /dev/userfaultfd misc device. This device provides an alternative to the userfaultfd(2) syscall for the creation of new userfaultfds. The idea is, any userfaultfds created this way will be able to handle kernel faults, without the caller having any special capabilities. Access to this mechanism is instead restricted using e.g. standard filesystem permissions. Signed-off-by: Axel Rasmussen <axelrasmussen(a)google.com> --- fs/userfaultfd.c | 79 ++++++++++++++++++++++++++------ include/uapi/linux/userfaultfd.h | 4 ++ 2 files changed, 69 insertions(+), 14 deletions(-) diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c index aa0c47cb0d16..16d7573ab41a 100644 --- a/fs/userfaultfd.c +++ b/fs/userfaultfd.c @@ -29,6 +29,7 @@ #include <linux/ioctl.h> #include <linux/security.h> #include <linux/hugetlb.h> +#include <linux/miscdevice.h> int sysctl_unprivileged_userfaultfd __read_mostly; @@ -65,6 +66,8 @@ struct userfaultfd_ctx { unsigned int flags; /* features requested from the userspace */ unsigned int features; + /* whether or not to handle kernel faults */ + bool handle_kernel_faults; /* released */ bool released; /* memory mappings are changing because of non-cooperative event */ @@ -410,13 +413,8 @@ vm_fault_t handle_userfault(struct vm_fault *vmf, unsigned long reason) if (ctx->features & UFFD_FEATURE_SIGBUS) goto out; - if ((vmf->flags & FAULT_FLAG_USER) == 0 && - ctx->flags & UFFD_USER_MODE_ONLY) { - printk_once(KERN_WARNING "uffd: Set unprivileged_userfaultfd " - "sysctl knob to 1 if kernel faults must be handled " - "without obtaining CAP_SYS_PTRACE capability\n"); + if (!(vmf->flags & FAULT_FLAG_USER) && !ctx->handle_kernel_faults) goto out; - } /* * If it's already released don't get it. This avoids to loop @@ -2064,19 +2062,33 @@ static void init_once_userfaultfd_ctx(void *mem) seqcount_spinlock_init(&ctx->refile_seq, &ctx->fault_pending_wqh.lock); } -SYSCALL_DEFINE1(userfaultfd, int, flags) +static inline bool userfaultfd_allowed(bool is_syscall, int flags) +{ + bool kernel_faults = !(flags & UFFD_USER_MODE_ONLY); + bool allow_unprivileged = sysctl_unprivileged_userfaultfd; + + /* userfaultfd(2) access is controlled by sysctl + capability. */ + if (is_syscall && kernel_faults) { + if (!allow_unprivileged && !capable(CAP_SYS_PTRACE)) + return false; + } + + /* + * For /dev/userfaultfd, access is to be controlled using e.g. + * permissions on the device node. We assume this is correctly + * configured by userspace, so we simply allow access here. + */ + + return true; +} + +static int new_userfaultfd(bool is_syscall, int flags) { struct userfaultfd_ctx *ctx; int fd; - if (!sysctl_unprivileged_userfaultfd && - (flags & UFFD_USER_MODE_ONLY) == 0 && - !capable(CAP_SYS_PTRACE)) { - printk_once(KERN_WARNING "uffd: Set unprivileged_userfaultfd " - "sysctl knob to 1 if kernel faults must be handled " - "without obtaining CAP_SYS_PTRACE capability\n"); + if (!userfaultfd_allowed(is_syscall, flags)) return -EPERM; - } BUG_ON(!current->mm); @@ -2095,6 +2107,11 @@ SYSCALL_DEFINE1(userfaultfd, int, flags) refcount_set(&ctx->refcount, 1); ctx->flags = flags; ctx->features = 0; + /* + * If UFFD_USER_MODE_ONLY is not set, then userfaultfd_allowed() above + * decided that kernel faults were allowed and should be handled. + */ + ctx->handle_kernel_faults = !(flags & UFFD_USER_MODE_ONLY); ctx->released = false; atomic_set(&ctx->mmap_changing, 0); ctx->mm = current->mm; @@ -2110,8 +2127,42 @@ SYSCALL_DEFINE1(userfaultfd, int, flags) return fd; } +SYSCALL_DEFINE1(userfaultfd, int, flags) +{ + return new_userfaultfd(true, flags); +} + +static int userfaultfd_dev_open(struct inode *inode, struct file *file) +{ + return 0; +} + +static long userfaultfd_dev_ioctl(struct file *file, unsigned int cmd, unsigned long flags) +{ + if (cmd != USERFAULTFD_IOC_NEW) + return -EINVAL; + + return new_userfaultfd(false, flags); +} + +static const struct file_operations userfaultfd_dev_fops = { + .open = userfaultfd_dev_open, + .unlocked_ioctl = userfaultfd_dev_ioctl, + .compat_ioctl = compat_ptr_ioctl, + .owner = THIS_MODULE, + .llseek = noop_llseek, +}; + +static struct miscdevice userfaultfd_misc = { + .minor = MISC_DYNAMIC_MINOR, + .name = "userfaultfd", + .fops = &userfaultfd_dev_fops +}; + static int __init userfaultfd_init(void) { + WARN_ON(misc_register(&userfaultfd_misc)); + userfaultfd_ctx_cachep = kmem_cache_create("userfaultfd_ctx_cache", sizeof(struct userfaultfd_ctx), 0, diff --git a/include/uapi/linux/userfaultfd.h b/include/uapi/linux/userfaultfd.h index ef739054cb1c..032a35b3bbd2 100644 --- a/include/uapi/linux/userfaultfd.h +++ b/include/uapi/linux/userfaultfd.h @@ -12,6 +12,10 @@ #include <linux/types.h> +/* ioctls for /dev/userfaultfd */ +#define USERFAULTFD_IOC 0xAA +#define USERFAULTFD_IOC_NEW _IOWR(USERFAULTFD_IOC, 0x00, int) + /* * If the UFFDIO_API is upgraded someday, the UFFDIO_UNREGISTER and * UFFDIO_WAKE ioctls should be defined as _IOW and not as _IOR. In -- 2.35.1.1178.g4f1659d476-goog

2 years, 1 month

2
5
0 0

Re: [PATCH 2/2] selftests/damon: make selftests executable

by Yuanchu Xie

> I don't recall why we decided to add the check in runner.sh - let's keep them > consistent with the rest of the scripts. If we get rid of the check, we can > make the change then. > > thanks, > -- Shuah It seems reasonable to add the x bit for these tests to be consistent with the rest. I also received an email from a patchwork-bot+linux-kselftest(a)kernel.org telling me my patch series was included in shuah/linux-kselftest.git, but that does not seem to be the case. Is this a bug? Sorry about the previous non-plain-text email. I never replied to anyone before and didn't know what I was doing. > Hello: > > > This series was applied to shuah/linux-kselftest.git (next) > > by Jakub Kicinski <kuba(a)kernel.org>: > > > On Fri, 18 Feb 2022 00:10:15 +0000 you wrote: > > These patches fixes trivial errors with building > > and running DAMON selftests. > > > > Yuanchu Xie (2): > > selftests/damon: add damon to selftests root Makefile > > selftests/damon: make selftests executable > > > > [...] > > > Here is the summary with links: > - [1/2] selftests/damon: add damon to selftests root Makefile > (no matching commit) > - [2/2] selftests/damon: make selftests executable > https://git.kernel.org/shuah/linux-kselftest/c/1335648f0b6f > > You are awesome, thank you! > -- > Deet-doot-dot, I am a bot. > https://korg.docs.kernel.org/patchwork/pwbot.html

2 years, 1 month

1
0
0 0

[RFC v1 00/10] roadtest: a driver testing framework

by Vincent Whitchurch

This patchset proposes roadtest, a device-driver testing framework. Drivers are tested under User Mode Linux (UML) and interact with mocked/modelled hardware. The tests and hardware models are written in Python, the former using Python's built-in unittest framework. Drivers are tested via their userspace interfaces. The hardware models allow tests to inject values into registers and assert that drivers control the hardware in the right way and react as expected to stimuli. Roadtest is meant to be used for relatively simple drivers, such as the ones part of the IIO, regulator and RTC subsystems. Questions and answers: = Why do we need this? There are a large amount of these kind of drivers in the kernel. Most of the hardware is not available in current CI systems so most drivers can only, at best, be build-tested there. Even basic soundness such as a driver successfully probing and binding to the devices it tries to be support cannot be tested. Drivers cannot be easily regression-tested to ensure that bugs fixed once do not get reintroduced. Many drivers support multiple related hardware variants, and far from all patch submitters have access to all the variants which the driver that they are patching supports, so there is no way for them to easily verify that they haven't broken something basic on a variant which they do not own. Furthermore, hardware can be used in many different configurations with drivers supporting many different devicetree properties, so even just having access to all the variants would be insufficient. On top of that, some of the chips measure environmental conditions such as temperature, so testing extreme cases may not be simple even if one has access to the hardware. All this makes development, modification, maintenance, and reviewing of these drivers harder than it necessarily needs to be. Roadtest hopes to make some of these things slightly easier by providing a framework to create hardware models/mocks and to write testcases which exercise drivers using these models. = Do you have some specific examples of the kind of code this could be used to test? Here is an example of a patch which can easily be regression-tested using roadtest (in fact, this series includes such a regression test) but is much harder to do so automatically with real hardware since it requires specific environmental conditions: iio: light: opt3001: Fixed timeout error when 0 lux https://lore.kernel.org/lkml/20210920125351.6569-1-valek@2n.cz/ Here is another example. This driver has code which correctly parses a documented devicetree property (amstaos,proximity-diodes) but which then fails to actually communicate this setting to the hardware in any way. Such code can be easily tested with roadtest since the framework integrates devicetree support and provides functions to assert that drivers writes expected registers with expected values: drivers/iio/light/tsl2772.c tsl2772_read_prox_diodes() (Both the above examples happen to be from the same subsystem but that should in no way be taken to imply that such issues are unique to that subsystem or that that subsystem has more of them.) = How does this relate to kselftests? Tests in kselftests also test kernel code using the userspace interfaces, but that's about what's common between the frameworks. kselftests has other goals and does not provide any kind of mechanism for hardware mocking. = How does this relate to kunit? Kunit is for unit testing of functions in kernel code, and is not meant for testing kernel code via userspace interfaces. It could in theory be used to test some of the simple drivers too, but that would require (1) a large amount of mocking code in various kernel frameworks, and, more importantly, (2) refactoring of the drivers to be tested. This can be contrasted with roadtest which works with mostly unmodified drivers and which mocks the hardware at the lowest level without having to change kernel frameworks. = How do I use it? See Documentation/dev-tools/roadtest.rst added by the documentation patch for more information about running and writing tests using this framework. = What's included in the patchset? The current framework allows developing tests for hardware which uses the I2C bus. Hardware models can also control GPIOs and use them to trigger interrupts. This series includes tests for some IIO, regulator and RTC drivers. The regulator and RTC tests depend on a few driver patches which are either in review or in linux-next. These are noted in the commit messages. The entire patch set, including the required dependencies, is also available in a git tree: https://github.com/vwax/linux/commits/roadtest/rfc-v1 Cc: linux-kernel(a)vger.kernel.org Cc: devicetree(a)vger.kernel.org Cc: linux-um(a)lists.infradead.org Cc: shuah(a)kernel.org Cc: brendanhiggins(a)google.com Cc: linux-kselftest(a)vger.kernel.org Cc: jic23(a)kernel.org Cc: linux-iio(a)vger.kernel.org Cc: lgirdwood(a)gmail.com Cc: broonie(a)kernel.org Cc: a.zummo(a)towertech.it Cc: alexandre.belloni(a)bootlin.com Cc: linux-rtc(a)vger.kernel.org Cc: corbet(a)lwn.net Cc: linux-doc(a)vger.kernel.org Vincent Whitchurch (10): roadtest: import libvhost-user from QEMU roadtest: add C backend roadtest: add framework roadtest: add base config roadtest: add build files roadtest: add documentation iio: light: opt3001: add roadtest iio: light: vcnl4000: add roadtest regulator: tps62864: add roadtest rtc: pcf8563: add roadtest Documentation/dev-tools/index.rst | 1 + Documentation/dev-tools/roadtest.rst | 669 ++++ tools/testing/roadtest/.gitignore | 2 + tools/testing/roadtest/Dockerfile | 25 + tools/testing/roadtest/Makefile | 84 + tools/testing/roadtest/init.sh | 19 + tools/testing/roadtest/pyproject.toml | 10 + tools/testing/roadtest/requirements.txt | 4 + tools/testing/roadtest/roadtest/__init__.py | 2 + .../roadtest/roadtest/backend/__init__.py | 0 .../roadtest/roadtest/backend/backend.py | 32 + .../testing/roadtest/roadtest/backend/gpio.py | 111 + .../testing/roadtest/roadtest/backend/i2c.py | 123 + .../testing/roadtest/roadtest/backend/main.py | 13 + .../testing/roadtest/roadtest/backend/mock.py | 20 + .../roadtest/roadtest/backend/test_gpio.py | 98 + .../roadtest/roadtest/backend/test_i2c.py | 84 + .../testing/roadtest/roadtest/cmd/__init__.py | 0 tools/testing/roadtest/roadtest/cmd/main.py | 146 + tools/testing/roadtest/roadtest/cmd/remote.py | 48 + .../roadtest/roadtest/core/__init__.py | 0 .../testing/roadtest/roadtest/core/control.py | 52 + .../roadtest/roadtest/core/devicetree.py | 155 + .../roadtest/roadtest/core/hardware.py | 94 + tools/testing/roadtest/roadtest/core/log.py | 42 + .../testing/roadtest/roadtest/core/modules.py | 38 + .../testing/roadtest/roadtest/core/opslog.py | 35 + tools/testing/roadtest/roadtest/core/proxy.py | 48 + tools/testing/roadtest/roadtest/core/suite.py | 286 ++ tools/testing/roadtest/roadtest/core/sysfs.py | 77 + .../roadtest/roadtest/core/test_control.py | 35 + .../roadtest/roadtest/core/test_devicetree.py | 31 + .../roadtest/roadtest/core/test_hardware.py | 41 + .../roadtest/roadtest/core/test_log.py | 54 + .../roadtest/roadtest/core/test_opslog.py | 27 + .../roadtest/roadtest/tests/__init__.py | 0 .../roadtest/roadtest/tests/base/config | 84 + .../roadtest/roadtest/tests/iio/__init__.py | 0 .../roadtest/roadtest/tests/iio/config | 1 + .../roadtest/roadtest/tests/iio/iio.py | 112 + .../roadtest/tests/iio/light/__init__.py | 0 .../roadtest/roadtest/tests/iio/light/config | 2 + .../roadtest/tests/iio/light/test_opt3001.py | 95 + .../roadtest/tests/iio/light/test_vcnl4000.py | 132 + .../roadtest/tests/iio/light/test_vcnl4010.py | 282 ++ .../roadtest/tests/iio/light/test_vcnl4040.py | 104 + .../roadtest/tests/iio/light/test_vcnl4200.py | 96 + .../roadtest/tests/regulator/__init__.py | 0 .../roadtest/roadtest/tests/regulator/config | 4 + .../roadtest/tests/regulator/test_tps62864.py | 187 ++ .../roadtest/roadtest/tests/rtc/__init__.py | 0 .../roadtest/roadtest/tests/rtc/config | 1 + .../roadtest/roadtest/tests/rtc/rtc.py | 73 + .../roadtest/tests/rtc/test_pcf8563.py | 348 ++ tools/testing/roadtest/src/.gitignore | 1 + tools/testing/roadtest/src/backend.c | 884 +++++ .../src/libvhost-user/include/atomic.h | 310 ++ .../src/libvhost-user/libvhost-user.c | 2885 +++++++++++++++++ .../src/libvhost-user/libvhost-user.h | 691 ++++ 59 files changed, 8798 insertions(+) create mode 100644 Documentation/dev-tools/roadtest.rst create mode 100644 tools/testing/roadtest/.gitignore create mode 100644 tools/testing/roadtest/Dockerfile create mode 100644 tools/testing/roadtest/Makefile create mode 100755 tools/testing/roadtest/init.sh create mode 100644 tools/testing/roadtest/pyproject.toml create mode 100644 tools/testing/roadtest/requirements.txt create mode 100644 tools/testing/roadtest/roadtest/__init__.py create mode 100644 tools/testing/roadtest/roadtest/backend/__init__.py create mode 100644 tools/testing/roadtest/roadtest/backend/backend.py create mode 100644 tools/testing/roadtest/roadtest/backend/gpio.py create mode 100644 tools/testing/roadtest/roadtest/backend/i2c.py create mode 100644 tools/testing/roadtest/roadtest/backend/main.py create mode 100644 tools/testing/roadtest/roadtest/backend/mock.py create mode 100644 tools/testing/roadtest/roadtest/backend/test_gpio.py create mode 100644 tools/testing/roadtest/roadtest/backend/test_i2c.py create mode 100644 tools/testing/roadtest/roadtest/cmd/__init__.py create mode 100644 tools/testing/roadtest/roadtest/cmd/main.py create mode 100644 tools/testing/roadtest/roadtest/cmd/remote.py create mode 100644 tools/testing/roadtest/roadtest/core/__init__.py create mode 100644 tools/testing/roadtest/roadtest/core/control.py create mode 100644 tools/testing/roadtest/roadtest/core/devicetree.py create mode 100644 tools/testing/roadtest/roadtest/core/hardware.py create mode 100644 tools/testing/roadtest/roadtest/core/log.py create mode 100644 tools/testing/roadtest/roadtest/core/modules.py create mode 100644 tools/testing/roadtest/roadtest/core/opslog.py create mode 100644 tools/testing/roadtest/roadtest/core/proxy.py create mode 100644 tools/testing/roadtest/roadtest/core/suite.py create mode 100644 tools/testing/roadtest/roadtest/core/sysfs.py create mode 100644 tools/testing/roadtest/roadtest/core/test_control.py create mode 100644 tools/testing/roadtest/roadtest/core/test_devicetree.py create mode 100644 tools/testing/roadtest/roadtest/core/test_hardware.py create mode 100644 tools/testing/roadtest/roadtest/core/test_log.py create mode 100644 tools/testing/roadtest/roadtest/core/test_opslog.py create mode 100644 tools/testing/roadtest/roadtest/tests/__init__.py create mode 100644 tools/testing/roadtest/roadtest/tests/base/config create mode 100644 tools/testing/roadtest/roadtest/tests/iio/__init__.py create mode 100644 tools/testing/roadtest/roadtest/tests/iio/config create mode 100644 tools/testing/roadtest/roadtest/tests/iio/iio.py create mode 100644 tools/testing/roadtest/roadtest/tests/iio/light/__init__.py create mode 100644 tools/testing/roadtest/roadtest/tests/iio/light/config create mode 100644 tools/testing/roadtest/roadtest/tests/iio/light/test_opt3001.py create mode 100644 tools/testing/roadtest/roadtest/tests/iio/light/test_vcnl4000.py create mode 100644 tools/testing/roadtest/roadtest/tests/iio/light/test_vcnl4010.py create mode 100644 tools/testing/roadtest/roadtest/tests/iio/light/test_vcnl4040.py create mode 100644 tools/testing/roadtest/roadtest/tests/iio/light/test_vcnl4200.py create mode 100644 tools/testing/roadtest/roadtest/tests/regulator/__init__.py create mode 100644 tools/testing/roadtest/roadtest/tests/regulator/config create mode 100644 tools/testing/roadtest/roadtest/tests/regulator/test_tps62864.py create mode 100644 tools/testing/roadtest/roadtest/tests/rtc/__init__.py create mode 100644 tools/testing/roadtest/roadtest/tests/rtc/config create mode 100644 tools/testing/roadtest/roadtest/tests/rtc/rtc.py create mode 100644 tools/testing/roadtest/roadtest/tests/rtc/test_pcf8563.py create mode 100644 tools/testing/roadtest/src/.gitignore create mode 100644 tools/testing/roadtest/src/backend.c create mode 100644 tools/testing/roadtest/src/libvhost-user/include/atomic.h create mode 100644 tools/testing/roadtest/src/libvhost-user/libvhost-user.c create mode 100644 tools/testing/roadtest/src/libvhost-user/libvhost-user.h -- 2.34.1

2 years, 1 month

6
26
0 0

[PATCH PROPER] Documentation: kunit: change complete_and_exit to kthread_complete_and_exit

by Andreas-Christian Hagau

Commit cead18552660 ("exit: Rename complete_and_exit to kthread_complete_and_exit") renamed complete_and_exit to kthread_complete_and_exit. CC: Brendan Higgins <brendanhiggins(a)google.com> CC: Jonathan Corbet <corbet(a)lwn.net> CC: linux-kselftest(a)vger.kernel.org CC: kunit-dev(a)googlegroups.com CC: linux-doc(a)vger.kernel.org CC: linux-kernel(a)vger.kernel.org Signed-off-by: Andreas-Christian Hagau <ach(a)hagau.se> --- Documentation/dev-tools/kunit/architecture.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/dev-tools/kunit/architecture.rst b/Documentation/dev-tools/kunit/architecture.rst index ff9c85a0bff21..cf9e6e3eeae4c 100644 --- a/Documentation/dev-tools/kunit/architecture.rst +++ b/Documentation/dev-tools/kunit/architecture.rst @@ -125,7 +125,7 @@ All expectations/assertions are formatted as: ``void __noreturn kunit_try_catch_throw(struct kunit_try_catch *try_catch)``. - ``kunit_try_catch_throw`` calls function: - ``void complete_and_exit(struct completion *, long) __noreturn;`` + ``void kthread_complete_and_exit(struct completion *, long) __noreturn;`` and terminates the special thread context. - ``<op>`` denotes a check with options: ``TRUE`` (supplied property -- 2.35.1

2 years, 1 month

1
0
0 0

[PATCH 1/2] selftests/lkdtm: add config and turn off CFI_FORWARD_PROTO

by Muhammad Usama Anjum

Add config options which are needed for LKDTM sub-tests. STACKLEAK_ERASING test needs GCC_PLUGIN_STACKLEAK config. READ_AFTER_FREE and READ_BUDDY_AFTER_FREE tests need INIT_ON_FREE_DEFAULT_ON config. CFI_FORWARD_PROTO always fails as there is no active CFI system of some kind. Turn it off for now by default until proper support. Cc: Kees Cook <keescook(a)chromium.org> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Fixes: 46d1a0f03d66 ("selftests/lkdtm: Add tests for LKDTM targets") Signed-off-by: Muhammad Usama Anjum <usama.anjum(a)collabora.com> --- tools/testing/selftests/lkdtm/config | 2 ++ tools/testing/selftests/lkdtm/tests.txt | 2 +- 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/tools/testing/selftests/lkdtm/config b/tools/testing/selftests/lkdtm/config index 46f39ee762086..adc9fa60057c5 100644 --- a/tools/testing/selftests/lkdtm/config +++ b/tools/testing/selftests/lkdtm/config @@ -2,8 +2,10 @@ CONFIG_LKDTM=y CONFIG_DEBUG_LIST=y CONFIG_SLAB_FREELIST_HARDENED=y CONFIG_FORTIFY_SOURCE=y +CONFIG_GCC_PLUGIN_STACKLEAK=y CONFIG_HARDENED_USERCOPY=y CONFIG_RANDOMIZE_KSTACK_OFFSET_DEFAULT=y +CONFIG_INIT_ON_FREE_DEFAULT_ON=y CONFIG_INIT_ON_ALLOC_DEFAULT_ON=y CONFIG_UBSAN=y CONFIG_UBSAN_BOUNDS=y diff --git a/tools/testing/selftests/lkdtm/tests.txt b/tools/testing/selftests/lkdtm/tests.txt index 6b36b7f5dcf96..aa947b0ce1eeb 100644 --- a/tools/testing/selftests/lkdtm/tests.txt +++ b/tools/testing/selftests/lkdtm/tests.txt @@ -72,7 +72,7 @@ USERCOPY_STACK_FRAME_FROM USERCOPY_STACK_BEYOND USERCOPY_KERNEL STACKLEAK_ERASING OK: the rest of the thread stack is properly erased -CFI_FORWARD_PROTO +#CFI_FORWARD_PROTO FORTIFIED_STRSCPY FORTIFIED_OBJECT FORTIFIED_SUBOBJECT -- 2.30.2

2 years, 1 month

2
14
0 0

opportunity

by Allen S

Hello, I lead family investment vehicles who want to invest a proportion of their funds with a trust party . Please if you are interested in discussing investment in your sector? Please email, or simply write to me here. I value promptness and will make every attempt to respond within a short time. Thank you. Allen S.

2 years, 1 month

1
0
0 0

Hello,

by Seyba Daniel

Hello, I am so sorry contacting you in this means especially when we have never met before. I urgently seek your service to represent me in investing in your region / country and you will be rewarded for your service without affecting your present job with very little time invested in it. My interest is in buying real estate, private schools or companies with potentials for rapid growth in long terms. So please confirm interest by responding back. My dearest regards Seyba Daniel

2 years, 1 month

1
0
0 0

[GIT PULL] Kselftest update for Linux 5.18-rc3

by Shuah Khan

Hi Linus, Please pull the following Kselftest update for Linux 5.18-rc3. This Kselftest fixes update consists of a mqueue perf test memory leak bug fix. mq_perf_tests fail to call CPU_FREE to free memory allocated by CPU_SET. diff is attached. thanks, -- Shuah ---------------------------------------------------------------- The following changes since commit 79ee8aa31d518c1fd5f3b1b1ac39dd1fb4dc7039: selftests/harness: Pass variant to teardown (2022-04-04 13:37:48 -0600) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest tags/linux-kselftest-fixes-5.18-rc3 for you to fetch changes up to ce64763c63854b4079f2e036638aa881a1fb3fbc: testing/selftests/mqueue: Fix mq_perf_tests to free the allocated cpu set (2022-04-12 13:54:49 -0600) ---------------------------------------------------------------- linux-kselftest-fixes-5.18-rc3 This Kselftest fixes update consists of a mqueue perf test memory leak bug fix. mq_perf_tests fail to call CPU_FREE to free memory allocated by CPU_SET. ---------------------------------------------------------------- Athira Rajeev (1): testing/selftests/mqueue: Fix mq_perf_tests to free the allocated cpu set tools/testing/selftests/mqueue/mq_perf_tests.c | 25 +++++++++++++++++-------- 1 file changed, 17 insertions(+), 8 deletions(-) ----------------------------------------------------------------

2 years, 1 month

2
1
0 0

[PATCH] Makefile: Fix separate output directory build of kselftests

by Muhammad Usama Anjum

Build of kselftests fail if kernel's top most Makefile is used for running or building kselftests with separate output directory. The absolute path is needed to reference other files during this kind of build. Set KBUILD_ABS_SRCTREE to use absolute path during the build. It fixes the following different types of errors: make kselftest-all O=/linux_mainline/build Makefile:1080: ../scripts/Makefile.extrawarn: No such file or directory make kselftest-all O=build Makefile:1080: ../scripts/Makefile.extrawarn: No such file or directory Signed-off-by: Muhammad Usama Anjum <usama.anjum(a)collabora.com> --- I've tested this patch on top of next-20220217. The latest next-20220222 have missing patches. --- Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index 86f633c2809ea..62b3eb8a102ab 100644 --- a/Makefile +++ b/Makefile @@ -1411,10 +1411,10 @@ tools/%: FORCE PHONY += kselftest kselftest: - $(Q)$(MAKE) -C $(srctree)/tools/testing/selftests run_tests + $(Q)$(MAKE) -C $(srctree)/tools/testing/selftests KBUILD_ABS_SRCTREE=1 run_tests kselftest-%: FORCE - $(Q)$(MAKE) -C $(srctree)/tools/testing/selftests $* + $(Q)$(MAKE) -C $(srctree)/tools/testing/selftests KBUILD_ABS_SRCTREE=1 $* PHONY += kselftest-merge kselftest-merge: -- 2.30.2

2 years, 1 month

3
9
0 0

[RFC V1 PATCH 0/5] selftests: KVM: selftests for fd-based approach of supporting private memory

by Vishal Annapurve

This 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. 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. Any suggestions regarding implementing this ioctl alternatively/cleanly are appreciated. priv_memfd_test.c file adds a suite of two basic selftests to access private memory from the guest via private/shared access and checking if the contents can be leaked to/accessed by vmm via shared memory view. Test results: 1) PMPAT - PrivateMemoryPrivateAccess test passes 2) PMSAT - PrivateMemorySharedAccess test fails currently and needs more analysis to understand the reason of failure. Important - Below patch is needed to ensure host kernel crash is avoided while running these tests: https://github.com/vishals4gh/linux/commit/b9adedf777ad84af39042e9c19899600… Github link for the patches posted as part of this series: https://github.com/vishals4gh/linux/commits/priv_memfd_selftests_v1 Note that this series is dependent on Chao's v5 patches mentioned above applied on top of 5.17. Vishal Annapurve (5): x86: kvm: HACK: Allow testing of priv memfd approach selftests: kvm: Fix inline assembly for hypercall selftests: kvm: Add a basic selftest test priv memfd selftests: kvm: priv_memfd_test: Add support for memory conversion selftests: kvm: priv_memfd_test: Add shared access test arch/x86/include/uapi/asm/kvm_para.h | 1 + arch/x86/kvm/mmu/mmu.c | 9 +- arch/x86/kvm/x86.c | 16 +- include/linux/kvm_host.h | 3 + tools/testing/selftests/kvm/Makefile | 1 + .../selftests/kvm/lib/x86_64/processor.c | 2 +- tools/testing/selftests/kvm/priv_memfd_test.c | 410 ++++++++++++++++++ virt/kvm/kvm_main.c | 2 +- 8 files changed, 436 insertions(+), 8 deletions(-) create mode 100644 tools/testing/selftests/kvm/priv_memfd_test.c -- 2.35.1.1178.g4f1659d476-goog

2 years, 1 month

5
10
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-kselftest-mirror April 2022