- Linux-kselftest-mirror - lists.linaro.org

[PATCH 0/5] mm/migrate: avoid device private invalidations

by Ralph Campbell

The goal for this series is to avoid device private memory TLB invalidations when migrating a range of addresses from system memory to device private memory and some of those pages have already been migrated. The approach taken is to introduce a new mmu notifier invalidation event type and use that in the device driver to skip invalidation callbacks from migrate_vma_setup(). The device driver is also then expected to handle device MMU invalidations as part of the migrate_vma_setup(), migrate_vma_pages(), migrate_vma_finalize() process. Note that this is opt-in. A device driver can simply invalidate its MMU in the mmu notifier callback and not handle MMU invalidations in the migration sequence. This series is based on linux-5.8.0-rc4 and the patches I sent for ("mm/hmm/nouveau: add PMD system memory mapping") https://lore.kernel.org/linux-mm/20200701225352.9649-1-rcampbell@nvidia.com There are no logical dependencies, but there would be merge conflicts which could be resolved if this were to be applied before the other series. Also, this replaces the need for the following two patches I sent: ("mm: fix migrate_vma_setup() src_owner and normal pages") https://lore.kernel.org/linux-mm/20200622222008.9971-1-rcampbell@nvidia.com ("nouveau: fix mixed normal and device private page migration") https://lore.kernel.org/lkml/20200622233854.10889-3-rcampbell@nvidia.com Ralph Campbell (5): nouveau: fix storing invalid ptes mm/migrate: add a direction parameter to migrate_vma mm/notifier: add migration invalidation type nouveau/svm: use the new migration invalidation mm/hmm/test: use the new migration invalidation arch/powerpc/kvm/book3s_hv_uvmem.c | 2 ++ drivers/gpu/drm/nouveau/nouveau_dmem.c | 13 ++++++-- drivers/gpu/drm/nouveau/nouveau_svm.c | 10 +++++- drivers/gpu/drm/nouveau/nouveau_svm.h | 1 + .../drm/nouveau/nvkm/subdev/mmu/vmmgp100.c | 13 +++++--- include/linux/migrate.h | 12 +++++-- include/linux/mmu_notifier.h | 7 ++++ lib/test_hmm.c | 33 +++++++++++-------- mm/migrate.c | 13 ++++++-- 9 files changed, 77 insertions(+), 27 deletions(-) -- 2.20.1

4 years, 6 months

3
9
0 0

[PATCH v3 0/5] mm/hmm/nouveau: add PMD system memory mapping

by Ralph Campbell

The goal for this series is to introduce the hmm_pfn_to_map_order() function. This allows a device driver to know that a given 4K PFN is actually mapped by the CPU using a larger sized CPU page table entry and therefore the device driver can safely map system memory using larger device MMU PTEs. The series is based on 5.8.0-rc3 and is intended for Jason Gunthorpe's hmm tree. These were originally part of a larger series: https://lore.kernel.org/linux-mm/20200619215649.32297-1-rcampbell@nvidia.co… Changes in v3: Replaced the HMM_PFN_P[MU]D flags with hmm_pfn_to_map_order() to indicate the size of the CPU mapping. Changes in v2: Make the hmm_range_fault() API changes into a separate series and add two output flags for PMD/PUD instead of a single compund page flag as suggested by Jason Gunthorpe. Make the nouveau page table changes a separate patch as suggested by Ben Skeggs. Only add support for 2MB nouveau mappings initially since changing the 1:1 CPU/GPU page table size assumptions requires a bigger set of changes. Rebase to 5.8.0-rc3. Ralph Campbell (5): nouveau/hmm: fault one page at a time mm/hmm: add hmm_mapping order nouveau: fix mapping 2MB sysmem pages nouveau/hmm: support mapping large sysmem pages hmm: add tests for HMM_PFN_PMD flag drivers/gpu/drm/nouveau/nouveau_svm.c | 236 ++++++++---------- drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c | 5 +- .../drm/nouveau/nvkm/subdev/mmu/vmmgp100.c | 82 ++++++ include/linux/hmm.h | 24 +- lib/test_hmm.c | 4 + lib/test_hmm_uapi.h | 4 + mm/hmm.c | 14 +- tools/testing/selftests/vm/hmm-tests.c | 76 ++++++ 8 files changed, 299 insertions(+), 146 deletions(-) -- 2.20.1

4 years, 6 months

3
8
0 0

[PATCH v2 0/2] mm/migrate: optimize migrate_vma_setup() for holes

by Ralph Campbell

A simple optimization for migrate_vma_*() when the source vma is not an anonymous vma and a new test case to exercise it. This is based on linux-mm and is for Andrew Morton's tree. Changes in v2: Do the same check for vma_is_anonymous() for pte_none(). Don't increment cpages if the page isn't migrating. Ralph Campbell (2): mm/migrate: optimize migrate_vma_setup() for holes mm/migrate: add migrate-shared test for migrate_vma_*() mm/migrate.c | 16 ++++++++++-- tools/testing/selftests/vm/hmm-tests.c | 35 ++++++++++++++++++++++++++ 2 files changed, 49 insertions(+), 2 deletions(-) -- 2.20.1

4 years, 6 months

1
2
0 0

[PATCH 0/2] mm/migrate: optimize migrate_vma_setup() for holes

by Ralph Campbell

A simple optimization for migrate_vma_*() when the source vma is not an anonymous vma and a new test case to exercise it. This is based on linux-mm and is for Andrew Morton's tree. Ralph Campbell (2): mm/migrate: optimize migrate_vma_setup() for holes mm/migrate: add migrate-shared test for migrate_vma_*() mm/migrate.c | 6 ++++- tools/testing/selftests/vm/hmm-tests.c | 35 ++++++++++++++++++++++++++ 2 files changed, 40 insertions(+), 1 deletion(-) -- 2.20.1

4 years, 6 months

2
4
0 0

[PATCH for-next/seccomp 0/3] Check ENOSYS under tracing

by Kees Cook

Hi, This expands the seccomp selftest to poke a architectural behavior corner that Keno Fischer noticed[1]. In the process, I took the opportunity to do the kselftest harness variant refactoring I'd been meaning to do, which made adding this test much nicer. I'd prefer this went via the seccomp tree, as it builds on top of the other recent seccomp feature addition tests. Testing and reviews are welcome! :) Thanks, -Kees [1] https://lore.kernel.org/lkml/CABV8kRxA9mXPZwtYrjbAfOfFewhABHddipccgk-LQJO+Z… Kees Cook (3): selftests/harness: Clean up kern-doc for fixtures selftests/seccomp: Refactor to use fixture variants selftests/seccomp: Check ENOSYS under tracing tools/testing/selftests/kselftest_harness.h | 15 +- tools/testing/selftests/seccomp/seccomp_bpf.c | 217 ++++++------------ 2 files changed, 72 insertions(+), 160 deletions(-) -- 2.25.1

4 years, 6 months

3
8
0 0

[PATCH v19 00/12] Landlock LSM

by Mickaël Salaün

Hi, This new patch series is a light update of the previous one, with some minor fixes and cosmetic changes. All reviews have been taken into account. The SLOC count is 1299 for security/landlock/ and 1752 for tools/testing/selftest/landlock/ . Test coverage for security/landlock/ is 93.6% of lines. The code not covered only deals with internal kernel errors (e.g. memory allocation) and race conditions. The compiled documentation is available here: https://landlock.io/linux-doc/landlock-v19/security/landlock/index.html This series can be applied on top of v5.8-rc4 . This can be tested with CONFIG_SECURITY_LANDLOCK and CONFIG_SAMPLE_LANDLOCK. This patch series can be found in a Git repository here: https://github.com/landlock-lsm/linux/commits/landlock-v19 I would really appreciate constructive comments on this patch series. # Landlock LSM The goal of Landlock is to enable to restrict ambient rights (e.g. global filesystem access) for a set of processes. Because Landlock is a stackable LSM [1], it makes possible to create safe security sandboxes as new security layers in addition to the existing system-wide access-controls. This kind of sandbox is expected to help mitigate the security impact of bugs or unexpected/malicious behaviors in user-space applications. Landlock empowers any process, including unprivileged ones, to securely restrict themselves. Landlock is inspired by seccomp-bpf but instead of filtering syscalls and their raw arguments, a Landlock rule can restrict the use of kernel objects like file hierarchies, according to the kernel semantic. Landlock also takes inspiration from other OS sandbox mechanisms: XNU Sandbox, FreeBSD Capsicum or OpenBSD Pledge/Unveil. In this current form, Landlock misses some access-control features. This enables to minimize this patch series and ease review. This series still addresses multiple use cases, especially with the combined use of seccomp-bpf: applications with built-in sandboxing, init systems, security sandbox tools and security-oriented APIs [2]. Previous version: https://lore.kernel.org/lkml/20200526205322.23465-1-mic@digikod.net/ [1] https://lore.kernel.org/lkml/50db058a-7dde-441b-a7f9-f6837fe8b69f@schaufler… [2] https://lore.kernel.org/lkml/f646e1c7-33cf-333f-070c-0a40ad0468cd@digikod.n… Casey Schaufler (1): LSM: Infrastructure management of the superblock Mickaël Salaün (11): landlock: Add object management landlock: Add ruleset and domain management landlock: Set up the security framework and manage credentials landlock: Add ptrace restrictions fs,security: Add sb_delete hook landlock: Support filesystem access-control landlock: Add syscall implementation arch: Wire up landlock() syscall selftests/landlock: Add initial tests samples/landlock: Add a sandbox manager example landlock: Add user and kernel documentation Documentation/security/index.rst | 1 + Documentation/security/landlock/index.rst | 18 + Documentation/security/landlock/kernel.rst | 69 + Documentation/security/landlock/user.rst | 268 +++ MAINTAINERS | 11 + arch/Kconfig | 7 + arch/alpha/kernel/syscalls/syscall.tbl | 1 + arch/arm/tools/syscall.tbl | 1 + arch/arm64/include/asm/unistd.h | 2 +- arch/arm64/include/asm/unistd32.h | 2 + arch/ia64/kernel/syscalls/syscall.tbl | 1 + arch/m68k/kernel/syscalls/syscall.tbl | 1 + arch/microblaze/kernel/syscalls/syscall.tbl | 1 + arch/mips/kernel/syscalls/syscall_n32.tbl | 1 + arch/mips/kernel/syscalls/syscall_n64.tbl | 1 + arch/mips/kernel/syscalls/syscall_o32.tbl | 1 + arch/parisc/kernel/syscalls/syscall.tbl | 1 + arch/powerpc/kernel/syscalls/syscall.tbl | 1 + arch/s390/kernel/syscalls/syscall.tbl | 1 + arch/sh/kernel/syscalls/syscall.tbl | 1 + arch/sparc/kernel/syscalls/syscall.tbl | 1 + arch/um/Kconfig | 1 + arch/x86/entry/syscalls/syscall_32.tbl | 1 + arch/x86/entry/syscalls/syscall_64.tbl | 1 + arch/xtensa/kernel/syscalls/syscall.tbl | 1 + fs/super.c | 1 + include/linux/lsm_hook_defs.h | 1 + include/linux/lsm_hooks.h | 3 + include/linux/security.h | 4 + include/linux/syscalls.h | 3 + include/uapi/asm-generic/unistd.h | 4 +- include/uapi/linux/landlock.h | 302 +++ kernel/sys_ni.c | 3 + samples/Kconfig | 7 + samples/Makefile | 1 + samples/landlock/.gitignore | 1 + samples/landlock/Makefile | 15 + samples/landlock/sandboxer.c | 228 +++ security/Kconfig | 11 +- security/Makefile | 2 + security/landlock/Kconfig | 18 + security/landlock/Makefile | 4 + security/landlock/common.h | 20 + security/landlock/cred.c | 46 + security/landlock/cred.h | 58 + security/landlock/fs.c | 609 ++++++ security/landlock/fs.h | 60 + security/landlock/object.c | 66 + security/landlock/object.h | 91 + security/landlock/ptrace.c | 120 ++ security/landlock/ptrace.h | 14 + security/landlock/ruleset.c | 342 ++++ security/landlock/ruleset.h | 157 ++ security/landlock/setup.c | 40 + security/landlock/setup.h | 18 + security/landlock/syscall.c | 526 +++++ security/security.c | 51 +- security/selinux/hooks.c | 58 +- security/selinux/include/objsec.h | 6 + security/selinux/ss/services.c | 3 +- security/smack/smack.h | 6 + security/smack/smack_lsm.c | 35 +- tools/testing/selftests/Makefile | 1 + tools/testing/selftests/landlock/.gitignore | 2 + tools/testing/selftests/landlock/Makefile | 29 + tools/testing/selftests/landlock/base_test.c | 163 ++ tools/testing/selftests/landlock/common.h | 93 + tools/testing/selftests/landlock/config | 5 + tools/testing/selftests/landlock/fs_test.c | 1740 +++++++++++++++++ .../testing/selftests/landlock/ptrace_test.c | 321 +++ tools/testing/selftests/landlock/true.c | 5 + 71 files changed, 5611 insertions(+), 77 deletions(-) create mode 100644 Documentation/security/landlock/index.rst create mode 100644 Documentation/security/landlock/kernel.rst create mode 100644 Documentation/security/landlock/user.rst create mode 100644 include/uapi/linux/landlock.h create mode 100644 samples/landlock/.gitignore create mode 100644 samples/landlock/Makefile create mode 100644 samples/landlock/sandboxer.c create mode 100644 security/landlock/Kconfig create mode 100644 security/landlock/Makefile create mode 100644 security/landlock/common.h create mode 100644 security/landlock/cred.c create mode 100644 security/landlock/cred.h create mode 100644 security/landlock/fs.c create mode 100644 security/landlock/fs.h create mode 100644 security/landlock/object.c create mode 100644 security/landlock/object.h create mode 100644 security/landlock/ptrace.c create mode 100644 security/landlock/ptrace.h create mode 100644 security/landlock/ruleset.c create mode 100644 security/landlock/ruleset.h create mode 100644 security/landlock/setup.c create mode 100644 security/landlock/setup.h create mode 100644 security/landlock/syscall.c create mode 100644 tools/testing/selftests/landlock/.gitignore create mode 100644 tools/testing/selftests/landlock/Makefile create mode 100644 tools/testing/selftests/landlock/base_test.c create mode 100644 tools/testing/selftests/landlock/common.h create mode 100644 tools/testing/selftests/landlock/config create mode 100644 tools/testing/selftests/landlock/fs_test.c create mode 100644 tools/testing/selftests/landlock/ptrace_test.c create mode 100644 tools/testing/selftests/landlock/true.c -- 2.27.0

4 years, 6 months

4
26
0 0

Re: [PATCH 2/4] KVM: x86: Introduce paravirt feature CR0/CR4 pinning

by Dave Hansen

On 7/9/20 9:07 AM, Andy Lutomirski wrote: > On Thu, Jul 9, 2020 at 8:56 AM Dave Hansen <dave.hansen(a)intel.com> wrote: >> On 7/9/20 8:44 AM, Andersen, John wrote: >>> Bits which are allowed to be pinned default to WP for CR0 and SMEP, >>> SMAP, and UMIP for CR4. >> I think it also makes sense to have FSGSBASE in this set. >> >> I know it hasn't been tested, but I think we should do the legwork to >> test it. If not in this set, can we agree that it's a logical next step? > I have no objection to pinning FSGSBASE, but is there a clear > description of the threat model that this whole series is meant to > address? The idea is to provide a degree of protection against an > attacker who is able to convince a guest kernel to write something > inappropriate to CR4, right? How realistic is this? If a quick search can find this: > https://googleprojectzero.blogspot.com/2017/05/exploiting-linux-kernel-via-… I'd pretty confident that the guys doing actual bad things have it in their toolbox too.

4 years, 6 months

2
1
0 0

[PATCH bpf] selftests: bpf: fix detach from sockmap tests

by Lorenz Bauer

Fix sockmap tests which rely on old bpf_prog_dispatch behaviour. In the first case, the tests check that detaching without giving a program succeeds. Since these are not the desired semantics, invert the condition. In the second case, the clean up code doesn't supply the necessary program fds. Reported-by: Martin KaFai Lau <kafai(a)fb.com> Signed-off-by: Lorenz Bauer <lmb(a)cloudflare.com> Fixes: bb0de3131f4c ("bpf: sockmap: Require attach_bpf_fd when detaching a program") --- tools/testing/selftests/bpf/test_maps.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/tools/testing/selftests/bpf/test_maps.c b/tools/testing/selftests/bpf/test_maps.c index 6a12a0e01e07..754cf611723e 100644 --- a/tools/testing/selftests/bpf/test_maps.c +++ b/tools/testing/selftests/bpf/test_maps.c @@ -789,19 +789,19 @@ static void test_sockmap(unsigned int tasks, void *data) } err = bpf_prog_detach(fd, BPF_SK_SKB_STREAM_PARSER); - if (err) { + if (!err) { printf("Failed empty parser prog detach\n"); goto out_sockmap; } err = bpf_prog_detach(fd, BPF_SK_SKB_STREAM_VERDICT); - if (err) { + if (!err) { printf("Failed empty verdict prog detach\n"); goto out_sockmap; } err = bpf_prog_detach(fd, BPF_SK_MSG_VERDICT); - if (err) { + if (!err) { printf("Failed empty msg verdict prog detach\n"); goto out_sockmap; } @@ -1090,19 +1090,19 @@ static void test_sockmap(unsigned int tasks, void *data) assert(status == 0); } - err = bpf_prog_detach(map_fd_rx, __MAX_BPF_ATTACH_TYPE); + err = bpf_prog_detach2(parse_prog, map_fd_rx, __MAX_BPF_ATTACH_TYPE); if (!err) { printf("Detached an invalid prog type.\n"); goto out_sockmap; } - err = bpf_prog_detach(map_fd_rx, BPF_SK_SKB_STREAM_PARSER); + err = bpf_prog_detach2(parse_prog, map_fd_rx, BPF_SK_SKB_STREAM_PARSER); if (err) { printf("Failed parser prog detach\n"); goto out_sockmap; } - err = bpf_prog_detach(map_fd_rx, BPF_SK_SKB_STREAM_VERDICT); + err = bpf_prog_detach2(verdict_prog, map_fd_rx, BPF_SK_SKB_STREAM_VERDICT); if (err) { printf("Failed parser prog detach\n"); goto out_sockmap; -- 2.25.1

4 years, 6 months

3
2
0 0

[PATCH] kunit: capture stderr on all make subprocess calls

by Will Chen

Direct stderr to subprocess.STDOUT so error messages get included in the subprocess.CalledProcessError exceptions output field. This results in more meaningful error messages for the user. This is already being done in the make_allyesconfig method. Do the same for make_mrproper, make_olddefconfig, and make methods. With this, failures on unclean trees [1] will give users an error message that includes: "The source tree is not clean, please run 'make ARCH=um mrproper'" [1] https://bugzilla.kernel.org/show_bug.cgi?id=205219 Signed-off-by: Will Chen <chenwi(a)google.com> --- tools/testing/kunit/kunit_kernel.py | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/tools/testing/kunit/kunit_kernel.py b/tools/testing/kunit/kunit_kernel.py index 63dbda2d029f..e20e2056cb38 100644 --- a/tools/testing/kunit/kunit_kernel.py +++ b/tools/testing/kunit/kunit_kernel.py @@ -34,7 +34,7 @@ class LinuxSourceTreeOperations(object): def make_mrproper(self): try: - subprocess.check_output(['make', 'mrproper']) + subprocess.check_output(['make', 'mrproper'], stderr=subprocess.STDOUT) except OSError as e: raise ConfigError('Could not call make command: ' + e) except subprocess.CalledProcessError as e: @@ -47,7 +47,7 @@ class LinuxSourceTreeOperations(object): if build_dir: command += ['O=' + build_dir] try: - subprocess.check_output(command, stderr=subprocess.PIPE) + subprocess.check_output(command, stderr=subprocess.STDOUT) except OSError as e: raise ConfigError('Could not call make command: ' + e) except subprocess.CalledProcessError as e: @@ -77,7 +77,7 @@ class LinuxSourceTreeOperations(object): if build_dir: command += ['O=' + build_dir] try: - subprocess.check_output(command) + subprocess.check_output(command, stderr=subprocess.STDOUT) except OSError as e: raise BuildError('Could not call execute make: ' + e) except subprocess.CalledProcessError as e: -- 2.27.0.383.g050319c2ae-goog

4 years, 6 months

2
1
0 0

[PATCH 0/4] Paravirtualized Control Register pinning

by John Andersen

The paravirtualized CR pinning patchset is a strengthened version of existing control registers pinning for paravritualized guests. It protects KVM guests from ROP based attacks which attempt to disable key security features. Virtualized Linux guests such as Kata Containers, AWS Lambda, and Chromos Termina will get this protection enabled by default when they update their kernel / configs. Using virtualization allows us to provide a stronger version of a proven exploit mitigation technique. We’ve patched KVM to create 6 new KVM specific MSRs used to query which bits may be pinned, and to set which bits are pinned high or low in control registers 0 and 4. Linux guest support was added so that non-kexec guests will be able to take advantage of this strengthened protection by default. A plan for enabling guests with kexec is proposed in this cover letter. As part of that plan, we add a command line flag that allows users to opt-in to the protection on boot if they have kexec built into their kernel, effectively opting out of kexec support. Hibernation and suspend to ram were enabled by updating the location where bits in control register 4 were saved to and restored from. The work also includes minor patches for QEMU to ensure reboot works by clearing the added MSRs and exposing the new CPUID feature bit. There is one SMM related selftest added in this patchset and another patch for kvm-unit-tests that will be sent separately. Thank you to Sean and Drew who reviewed v2, to Boris, Paolo, Andy, and Liran who reviewed v1, and to Sean, Dave, Kristen, and Rick who've provided feedback throughout. I appreciate your time spent reviewing and feedback. Here are the previous RFC versions of this patchset for reference RFC v2: https://lkml.org/lkml/2020/2/18/1162 RFC v1: https://lkml.org/lkml/2019/12/24/380 === High level overview of the changes === - A CPUID feature bit as well as MSRs were added to KVM. Guests can use the CPUID feature bit to determine if MSRs are available. Reading the first 2 MSRs returns the bits which may be pinned for CR0/4 respectively. The next 4 MSRs are writeable and allow the guest and host userspace to set which bits are pinned low or pinned high for CR0/4. - Hibernation and suspend-to-RAM are supported. This was done by updating mmu_cr4_features on feature identification of the boot CPU. As such, mmu_cr4_features is no longer read only after init. - CPU hotplug is supported. Pinning is per vCPU. When running as a guest pinning is requested after CPU identification for non-boot CPUs. The boot CPU requests pinning a directly after existing pinning is setup. - Nested virtualization is supported. SVM / VMX restore pinned bits on VM-Exit if they had been unset in the host VMCB / VMCS. - As suggested by Sean, unpinning of pinned bits on return from SMM due to modification of SMRAM will cause an unhandleable emulation fault resulting in termination of the guest. - kexec support is still pending, since the plan is a bit long it's been moved to the end of the cover letter. It talks about the decision to make a command line parameter, why we opt in to pinning (and effectively out of kexec). Being that those changes wouldn't be localized to KVM (and this patchset is on top of kvm/next). - As Paolo requested, a patch will be sent immediately following this patchset for kvm-unit-tests with the unit tests for general functionality. selftests are included for SMM specific functionality. === Chanages since RFCv2 === - Related to Drew's comments - Used linux/stringify.h in selftests - Added comments on why we don't use GUEST_* due to SMM trickiness. We opt not to use GUEST_SYNC() because we also have to make a sync call from SMM. As such, the address of the ucall struct we'd need to pass isn't something we can put into the machine code in a maintainable way. At least so far as I could tell. - Related to Sean's comments - Allowed pinning bits high or low rather than just high - Cleaner code path for guest and host when writing to MSRs - Didn't use read modify write behavior due to that requiring changes to selftest save restore code which made me suspect that there might be issues with other VMMs. The issue was because we read CR0/4 in the RWM operation on the MSR, we must do KVM_SET_REGS before KVM_SET_MSRS, we also had to call KVM_SET_SREGS and add checks for if we're in SMM or not. This made it a bit more messy overall so I went with the first approach Sean suggested where we just have pin high/low semantics. - If the guest writes values to the allowed MSRs that are not the correct value the wrmsr fails. - If SMRAM modification would result in unpinning bits we bail with X86EMUL_UNHANDLEABLE - Added silent restoration of pinned bits for SVM and VMX when they may have been modified in VMCB / VMCS. This didn't seem like a place were we'd want to inject a fault, please let me know if we should. === Description of changes and rational === Paravirtualized Control Register pinning is a strengthened version of existing protections on the Write Protect, Supervisor Mode Execution / Access Protection, and User-Mode Instruction Prevention bits. The existing protections prevent native_write_cr*() functions from writing values which disable those bits. This patchset prevents any guest writes to control registers from disabling pinned bits, not just writes from native_write_cr*(). This stops attackers within the guest from using ROP to disable protection bits. https://web.archive.org/web/20171029060939/http://www.blackbunny.io/linux-k… The protection is implemented by adding MSRs to KVM which contain the bits that are allowed to be pinned, and the bits which are pinned. The guest or userspace can enable bit pinning by reading MSRs to check which bits are allowed to be pinned, and then writing MSRs to set which bits they want pinned. Other hypervisors such as HyperV have implemented similar protections for Control Registers and MSRs; which security researchers have found effective. https://www.abatchy.com/2018/01/kernel-exploitation-4 We add a CR pin feature bit to the KVM cpuid, read only MSRs which guests use to identify which bits they may request be pinned, and CR pinned low/high MSRs which contain the pinned bits. Guests can request that KVM pin bits within control register 0 or 4 via the CR pinned MSRs. Writes to the MSRs fail if they include bits that aren't allowed to be pinned. Host userspace may clear or modify pinned bits at any time. Once pinned bits are set, the guest may pin more allowed bits, but may never clear pinned bits. In the event that the guest vCPU attempts to disable any of the pinned bits, the vCPU that issued the write is sent a general protection fault, and the register is left unchanged. When running with KVM guest support and paravirtualized CR pinning enabled, paravirtualized and existing pinning are setup at the same point on the boot CPU. Non-boot CPUs setup pinning upon identification. Pinning is not active when running in SMM. Entering SMM disables pinned bits. Writes to control registers within SMM would therefore trigger general protection faults if pinning was enforced. Upon exit from SMM, SMRAM is modified to ensure the values of CR0/4 that will be restored contain the correct values for pinned bits. CR0/4 values are then restored from SMRAM as usual. When running with nested virtualization, should pinned bits be cleared from host VMCS / VMCB, on VM-Exit, they will be silently restored. Should userspace expose the CR pining CPUID feature bit, it must zero CR pinned MSRs on reboot. If it does not, it runs the risk of having the guest enable pinning and subsequently cause general protection faults on next boot due to early boot code setting control registers to values which do not contain the pinned bits. Hibernation to disk and suspend-to-RAM are supported. identify_cpu was updated to ensure SMEP/SMAP/UMIP are present in mmu_cr4_features. This is necessary to ensure protections stay active during hibernation image restoration. Guests using the kexec system call currently do not support paravirtualized control register pinning. This is due to early boot code writing known good values to control registers, these values do not contain the protected bits. This is due to CPU feature identification being done at a later time, when the kernel properly checks if it can enable protections. As such, the pv_cr_pin command line option has been added which instructs the kernel to disable kexec in favor of enabling paravirtualized control register pinning. crashkernel is also disabled when the pv_cr_pin parameter is specified due to its reliance on kexec. When we make kexec compatible, we will still need a way for a kernel with support to know if the kernel it is attempting to load has support. If a kernel with this enabled attempts to kexec a kernel where this is not supported, it would trigger a fault almost immediately. Liran suggested adding a section to the built image acting as a flag to signify support for being kexec'd by a kernel with pinning enabled. Should that approach be implemented, it is likely that the command line flag (pv_cr_pin) would still be desired for some deprecation period. We wouldn't want the default behavior to change from being able to kexec older kernels to not being able to, as this might break some users workflows. Since we require that the user opt-in to break kexec we've held off on attempting to fix kexec in this patchset. This way no one sees any behavior they are not explicitly opting in to. Security conscious kernel configurations disable kexec already, per KSPP guidelines. Projects such as Kata Containers, AWS Lambda, ChromeOS Termina, and others using KVM to virtualize Linux will benefit from this protection without the need to specify pv_cr_pin on the command line. Pinning of sensitive CR bits has already been implemented to protect against exploits directly calling native_write_cr*(). The current protection cannot stop ROP attacks which jump directly to a MOV CR instruction. Guests running with paravirtualized CR pinning are now protected against the use of ROP to disable CR bits. The same bits that are being pinned natively may be pinned via the CR pinned MSRs. These bits are WP in CR0, and SMEP, SMAP, and UMIP in CR4. Future patches could implement similar MSRs to protect bits in MSRs. The NXE bit of the EFER MSR is a prime candidate. === Plan for kexec support === Andy's suggestion of a boot option has been incorporated as the pv_cr_pin command line option. Boris mentioned that short-term solutions become immutable. However, for the reasons outlined below we need a way for the user to opt-in to pinning over kexec if both are compiled in, and the command line parameter seems to be a good way to do that. Liran's proposed solution of a flag within the ELF would allow us to identify which kernels have support is assumed to be implemented in the following scenarios. We then have the following cases (without the addition of pv_cr_pin): - Kernel running without pinning enabled kexecs kernel with pinning. - Loaded kernel has kexec - Do not enable pinning - Loaded kernel lacks kexec - Enable pinning - Kernel running with pinning enabled kexecs kernel with pinning (as identified by ELF addition). - Okay - Kernel running with pinning enabled kexecs kernel without pinning (as identified by lack of ELF addition). - User is presented with an error saying that they may not kexec a kernel without pinning support. With the addition of pv_cr_pin we have the following situations: - Kernel running without pinning enabled kexecs kernel with pinning. - Loaded kernel has kexec - pv_cr_pin command line parameter present for new kernel - Enable pinning - pv_cr_pin command line parameter not present for new kernel - Do not enable pinning - Loaded kernel lacks kexec - Enable pinning - Kernel running with pinning enabled kexecs kernel with pinning (as identified by ELF addition). - Okay - Kernel running with kexec and pinning enabled (opt-in via pv_cr_pin) kexecs kernel without pinning (as identified by lack of ELF addition). - User is presented with an error saying that they have opted into pinning support and may not kexec a kernel without pinning support. Without the command line parameter I'm not sure how we could preserve users workflows which might rely on kexecing older kernels (ones which wouldn't have support). I see the benefit here being that users have to opt-in to the possibility of breaking their workflow, via their addition of the pv_cr_pin command line flag. Which could of course also be called nokexec. A deprecation period could then be chosen where eventually pinning takes preference over kexec and users are presented with the error if they try to kexec an older kernel. Input on this would be much appreciated, as well as if this is the best way to handle things or if there's another way that would be preferred. This is just what we were able to come up with to ensure users didn't get anything broken they didn't agree to have broken. Thanks, John John Andersen (4): X86: Update mmu_cr4_features during feature identification KVM: x86: Introduce paravirt feature CR0/CR4 pinning selftests: kvm: add test for CR pinning with SMM X86: Use KVM CR pin MSRs .../admin-guide/kernel-parameters.txt | 11 + Documentation/virt/kvm/msr.rst | 53 +++++ arch/x86/Kconfig | 10 + arch/x86/include/asm/kvm_host.h | 7 + arch/x86/include/asm/kvm_para.h | 28 +++ arch/x86/include/uapi/asm/kvm_para.h | 7 + arch/x86/kernel/cpu/common.c | 11 +- arch/x86/kernel/kvm.c | 39 ++++ arch/x86/kernel/setup.c | 12 +- arch/x86/kvm/cpuid.c | 3 +- arch/x86/kvm/emulate.c | 3 +- arch/x86/kvm/kvm_emulate.h | 2 +- arch/x86/kvm/svm/nested.c | 11 +- arch/x86/kvm/vmx/nested.c | 10 +- arch/x86/kvm/x86.c | 106 ++++++++- tools/testing/selftests/kvm/.gitignore | 1 + tools/testing/selftests/kvm/Makefile | 1 + .../selftests/kvm/include/x86_64/processor.h | 13 ++ .../selftests/kvm/x86_64/smm_cr_pin_test.c | 207 ++++++++++++++++++ 19 files changed, 521 insertions(+), 14 deletions(-) create mode 100644 tools/testing/selftests/kvm/x86_64/smm_cr_pin_test.c base-commit: 49b3deaad3452217d62dbd78da8df24eb0c7e169 -- 2.21.0

4 years, 6 months

7
21
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-kselftest-mirror