All of lore.kernel.org
 help / color / mirror / Atom feed
* [RFC PATCH v2 00/19] Hypervisor-Enforced Kernel Integrity
@ 2023-11-13  2:23 Mickaël Salaün
  2023-11-13  2:23 ` [RFC PATCH v2 01/19] virt: Introduce Hypervisor Enforced Kernel Integrity (Heki) Mickaël Salaün
                   ` (18 more replies)
  0 siblings, 19 replies; 44+ messages in thread
From: Mickaël Salaün @ 2023-11-13  2:23 UTC (permalink / raw)
  To: Borislav Petkov, Dave Hansen, H . Peter Anvin, Ingo Molnar,
	Kees Cook, Paolo Bonzini, Sean Christopherson, Thomas Gleixner,
	Vitaly Kuznetsov, Wanpeng Li
  Cc: Mickaël Salaün, Alexander Graf, Chao Peng, Edgecombe,
	Rick P, Forrest Yuan Yu, James Gowans, James Morris,
	John Andersen, Madhavan T . Venkataraman, Marian Rotariu,
	Mihai Donțu, Nicușor Cîțu, Thara Gopinath,
	Trilok Soni, Wei Liu, Will Deacon, Yu Zhang, Zahra Tarkhani,
	Ștefan Șicleru, dev, kvm, linux-hardening,
	linux-hyperv, linux-kernel, linux-security-module, qemu-devel,
	virtualization, x86, xen-devel

Hi,

This patch series is a proof-of-concept that implements new KVM features
(guest memory attributes, MBEC support, CR pinning) and defines a new
API to protect guest VMs. You can find related resources, including the
related commits here: https://github.com/heki-linux
We'll talk about this work and the related LVBS project at LPC:
* https://lpc.events/event/17/contributions/1486/
* https://lpc.events/event/17/contributions/1515/

The main idea being that kernel self-protection mechanisms should be
delegated to a more privileged part of the system, that is the
hypervisor.  It is still the role of the guest kernel to request such
restrictions according to its configuration. The high-level security
guarantees provided by the hypervisor are semantically the same as a
subset of those the kernel already enforces on itself (CR pinning
hardening and memory protections), but with much higher guarantees.

We'd like the mainline kernel to support such hardening features
leveraging virtualization. We're looking for reviews and comments that
can help mainline these two parts: the KVM implementation and the guest
kernel API layer designed to support different hypervisors. The guest
kernel API layer contains a global struct heki_hypervisor to share data
and functions between the common code and the hypervisor support code.
The struct heki_hypervisor enables to plug in different backend
implementations that are initialized with the heki_early_init() and
heki_late_init() calls. This RFC is a call for collaboration. There is a
lot to do, either on hypervisors, guest kernels or VMMs sides.

We took inspiration from previous patches, mainly the KVMI [1] [2] and
KVM CR-pinning [3] series, revamped and simplified relevant parts to fit
well with our goal, added support for MBEC, added two hypercalls, and
created a kernel API for VMs to request protection in a generic way that
can be leveraged by any hypervisor.

This patch series is based on the kvm-x86's guest_memfd branch [4] [5],
and requires the host to support MBEC. This can easily be checked with:
grep ept_mode_based_exec /proc/cpuinfo You can test it by enabling
CONFIG_HEKI, CONFIG_HEKI_TEST, CONFIG_KUNIT_DEFAULT_ENABLED, and adding
the heki_test=N boot argument to the guest as explained in the last
patch.

# Main changes since v1

We replaced the KVM's page tracking mechanism with the new per-page
attributes patch series [5]. The main difference is that the Heki
per-page attributes should be set by the guest instead of the host.
Indeed, the security policy is defined by the guest and the host should
only be able to enforce it on its side (e.g. device drivers).
Furthermore, the host may not be trusted by the guest
(i.e., confidential computing).

The main previous limitation was the statically enforced permissions.
Mechanisms that dynamically impact kernel executable memory are now
handled (e.g., kernel modules, tracepoints, eBPF JIT) but not
authenticated yet (see Current limitations).

This version supports dynamic kernel memory permissions.  However, the
kernel does not know about all the pages that have been assigned to the
guest. It knows only about the memory that has been passed to it. The
VMM is the one that knows about all the pages. In a future version, the
VMM will be enhanced to set the memory attributes for the pages that are
not known to the kernel. The kernel will then set permissions for the
pages that are actually mapped in its address space. Other pages are
left alone. In order to set EPT permissions for a page, KVM can lookup
the memory attributes for the page. If the attributes are not present,
KVM can use a default of read-write. This will make it efficient as
memory attributes need to be set only for the pages that the kernel
actually maps. Also, this will serve to implement a deny-by-default
policy for execute permissions.

We implemented a mechanism to dynamically synchronize the guest's memory
permissions with KVM. The original KVM_HC_LOCK_MEM_PAGE_RANGES hypercall
contained support for statically defined sections (text, rodata, etc).
It has been redesigned like this:

- The previous version accepted an array of physically contiguous
  ranges. This is appropriate for statically defined sections which are
  loaded in contiguous memory.  But, for other cases like module
  loading, the pages would be discontinuous. The current version of the
  hypercall accepts a page list to fix this.

- The previous version passed permission combinations. E.g.,
  HEKI_MEM_ATTR_EXEC would imply R_X. The current version passes
  permissions as memory attributes and each of the permissions must be
  separately specified. E.g., for text, (MEM_ATTR_READ | MEM_ATTR_EXEC)
  must be passed.

- The previous version locked down the permissions for guest pages so
  that once the permissions are set, they cannot be changed. In this
  version, permissions can be either immutable (MEM_ATTR_IMMUTABLE) or
  can be changed dynamically.  So, the hypercall has been renamed to
  KVM_HC_PROTECT_MEMORY. The dynamic setting of permissions is needed
  by the following features (probably not a complete list):
  - Kprobes and Optprobes
  - Static call optimization
  - Jump Label optimization
  - Ftrace and Livepatch
  - Module loading and unloading
  - eBPF JIT
  - Kexec
  - Kgdb

Examples:
- A text page can be made writable very briefly to install a probe or a
  trace.
- eBPF JIT can populate a writable page with code and make it
  read-execute.
- Module load can load read-only data into a writable page and make the
  page read-only.
- When pages are unmapped, their permissions in the EPT must revert to
  read-write.

KVM now sends a GP fault if a guest attempts to change its pinned CRs.

Because the VMM needs to be involved (e.g. device driver mapping memory)
and to know the guests' requested memory permissions, we implemented two
new kind of VM exits to be able to notify the VMM about guests' Heki
configurations and policy violations. Indeed, forwarding such signals to
the VMM could help improve attack detection, and react to such attempt
(e.g. log events, stop the VM).  Giving visibility to the VMM would also
enable to migrate VMs.

# Threat model

The main threat model is a malicious user space process exploiting a
kernel vulnerability to gain more privileges or to bypass the
access-control system.  This threat also covers attacks coming from
network or storage data (e.g., malformed network packet, inconsistent
drive content).

An extended threat model, following pKVM (and partially confidential
computing) efforts, is to protect as much as possible against the VMM.
This means that the security policy should mainly be defined and
requested by the guest to the hypervisor.  The limit of this approach is
the VMM's resources (e.g. exposed memory), which should also be
protected from the guest.

Considering all potential ways to compromise a kernel, Heki's goal is to
harden a sane kernel before a runtime attack to make it more difficult,
and potentially to cause such an attack to fail. We consider the kernel
itself to be partially malicious during its lifetime e.g., because a ROP
attack that could disable kernel self-protection mechanisms and make
kernel exploitation much easier. Indeed, an exploit is often split into
several stages, each bypassing some security measures. Getting the
guarantee that new kernel executable code is not possible increases the
cost of an attack, hopefully to the point that it is not worth it.

To protect against persistent attacks, complementary security mechanisms
should be used (e.g., kernel module signing, IMA, IPE, Lockdown).

# Prerequisites

For this set of features to be useful, guest kernels must be trusted by
the VM owners at boot time, before launching any user space processes
nor receiving potentially malicious network packets. It is then required
to have a security mechanism to provide or check this initial trust
(e.g., secure boot, kernel module signing).

# How does it work?

This implementation mainly leverages KVM capabilities to control the
Second Layer Address Translation (or the Two Dimensional Paging e.g.,
Intel's EPT or AMD's RVI/NPT) and Mode Based Execution Control (Intel's
MBEC) introduced with the Kaby Lake (7th generation) architecture. This
allows to set permissions on memory pages in a complementary way to the
guest kernel's managed memory permissions. If any permissions are set as
immutable, they are locked and there is no way back.

The KVM_HC_PROTECT_MEMORY hypercall enables the guest kernel to enforce
boot time mapped pages with the MEM_ATTR_{READ,WRITE,EXEC} attributes.

The current implementation walks the kernel address space and requests
permission enforcement according to the mappings present.  For instance,
it sets its .rodata (i.e., any const or __ro_after_init variables, which
includes critical security data such as LSM parameters) and .text
sections as non-writable, and the .text section is the only one where
kernel execution is initially allowed.  This is possible thanks to the
new MBEC support implemented by this series (otherwise the vDSO would
have to be executable). Thanks to this hardware support (VT-x, EPT and
MBEC), the performance impact of such guest protection is negligible at
run time.

A page can be mapped to multiple VAs. Each mapping can have different
permissions. Also each mapping may have a different page size. The
collective permissions across all the mappings must be applied in the
EPT. To make this possible, the implementation maintains permissions
counters for each 4K page (one counter each for read, write and
execute). The kernel address space is walked, the mappings are
identified, the counters are updated and the EPT permissions are set
based on the counters. Currently, the overhead from this whole process
can be visible during boot, especially with debugging features such as
KASAN.  We have some ideas that we will try out for a next series. We
welcome any suggestions to improve this part.

The KVM_HC_LOCK_CR_UPDATE hypercall enables guests to pin some of its
CPU control register flags (e.g., X86_CR0_WP, X86_CR4_SMEP,
X86_CR4_SMAP), which is another complementary hardening mechanism.

Two new kinds of VM exits are implemented: one for a guest Heki request
(i.e. hypercall), and another for a guest attempt to change its pinned
CRs. We haven't implemented such VM exit for memory-related events yet,
that will be part of a next series if the designed is approved.

When the guest attempts to update pinned CRs or to access memory in a
way that is not allowed, the VMM can then be notified and react to such
attack attempt. After that, if the VM is still running, KVM sends either
a GP fault or a page fault to the guest. The guest could then send a
signal to the user space process that triggered this policy violation
(not implemented).

Heki can be enabled with the heki=1 boot command argument.

# Similar implementations

Here is a non-exhaustive list of similar implementations that we looked
at and took some ideas from. Linux mainline doesn't support such
security features, let's change that!

Windows's Virtualization-Based Security is a proprietary technology
that provides a superset of this kind of security mechanism, relying on
Hyper-V and Virtual Trust Levels which enables to have light and secure
VM enforcing restrictions on a full guest VM. This includes several
components such as HVCI for code authenticity, or HyperGuard for
monitoring and protecting kernel code and data.

Samsung's Real-time Kernel Protection (RKP) and Huawei Hypervisor
Execution Environment (HHEE) rely on proprietary hypervisors to protect
some Android devices. They monitor critical kernel data (e.g., page
tables, credentials, selinux_enforcing).

The iOS Kernel Patch Protection (KPP/Watchtower) is a proprietary
solution running in EL3 that monitors and protects critical parts of the
kernel. It is now replaced with a hardware-based mechanism: KTTR/RoRgn.

Bitdefender's Hypervisor Memory Introspection (HVMI) is an open-source
(but out of tree) set of components leveraging virtualization. HVMI
implementation is very complex, and this approach implies potential
semantic gap issues (i.e., kernel data structures may change from one
version to another).

Linux Kernel Runtime Guard is an open-source kernel module that can
detect some kernel data illegitimate modifications. Because it is the
same kernel as the compromised one, an attacker could also bypass or
disable these checks.

Intel's Virtualization Based Hardening [6] [7] is an open-source
proof-of-concept of a thin hypervisor dedicated to guest protection. As
such, it cannot be used to manage several VMs.

# Similar Linux patches

The VM introspection [1] [2] patch series proposed a set of features to
put probes and introspect VMs for debugging and security reasons. We
changed and included the prewrite page tracking and the fault_gva parts.
Heki is much simpler because it focuses on guest hardening, not
introspection.

Paravirtualized Control Register pinning [3] added a set of KVM IOCTLs
to restrict some flags to be set. Heki doesn't implement such user space
interface, but only a dedicated hypercall to lock such registers. A
superset of these flags is configurable with Heki.

The Hypervisor Based Integrity patches [8] [9] only contain a generic
IPC mechanism (KVM_HC_UCALL hypercall) to request protection to the VMM.
The idea was to extend the KVM_SET_USER_MEMORY_REGION IOCTL to support
more permission than read-only.

# Current limitations

The main limitation of this patch series is that the executable kernel
data (e.g. kernel module) is only authenticated by the guest, not by the
hypervisor nor the VMM.  Because the hypervisor is highly privileged and
critical to the security of all the VMs, we don't want to implement a
code authentication mechanism in the hypervisor itself but delegate this
verification to something much less privileged. We are thinking of two
ways to solve this: implement this verification in the VMM or spawn a
dedicated special VM (similar to Windows's VBS). There are pros on cons
to each approach: complexity, verification code ownership (guest's or
VMM's), access to guest memory (i.e., confidential computing).

In this version, the immutable attribute is set on kernel text. So, it
is not possible to use ftrace, Kprobes, etc on kernel text (these are
still possible on module text). The immutable attribute is needed
because we do not have authentication in place yet.

All permissions changes must be authenticated. For changes that happen
during module loading, the module signature can be used for
authentication. But for intrinsic kernel features such as ftrace and
Kprobes, what do we use to authenticate a request? How do we make sure
that it is legitimate? We are looking for ideas in this area.

Also, each authentication involves a round trip from the guest to the
VMM and the hypervisor. This overhead could be significant. We welcome
ideas on improving this as well.

We currently use static address ranges to configure protections at boot
(see heki_arch_early_init). This is not compatible with KASLR yet, but
this will be handled in a next patch series.

Because the guest's virtual address translation is not protected by the
hypervisor, a compromised kernel could map existing physical pages into
arbitrary virtual addresses. The new Intel's Hypervisor-Managed Linear
Address Translation [10] (HLAT) could be used to extend the current
protection and cover this case.

ROP is not covered by this patch series. Guest kernels can still jump to
arbitrary executable pages according to their control-flow integrity
protection.

# Future work

New dynamic restrictions could enable to improve the protected data by
including security-sensitive data such as LSM states, seccomp filters,
keyrings... This requires support outside of the hypervisor.

An execute-only mode could also be useful (cf. XOM for KVM [11] [12]).

Extending register pinning (e.g., MSRs).

For now, MBEC is only supported on a bare metal machine as KVM host;
nested virtualization is not supported yet.  Being able to protect
nested guests might be possible but we need to figure out the potential
security implications.

Protecting the host would be useful, but that doesn't really fit with
the KVM model. The Protected KVM project is a first step to help in this
direction [13].

We only tested this with an Intel CPU, but this approach should work the
same with an AMD CPU starting with the Zen 2 generation and their Guest
Mode Execute Trap (GMET) capability.

We also kept some TODOs to highlight missing checks and code sharing
issues, and some pr_warn() calls to help understand how it works. Tests
need to be improved (e.g., invalid hypercall arguments).

We'll present this work at the Linux Plumbers Conference next week.

[1] https://lore.kernel.org/all/20211006173113.26445-1-alazar@bitdefender.com/
[2] https://www.linux-kvm.org/images/7/72/KVMForum2017_Introspection.pdf
[3] https://lore.kernel.org/all/20200617190757.27081-1-john.s.andersen@intel.com/
[4] https://github.com/kvm-x86/linux
[5] https://lore.kernel.org/all/20231027182217.3615211-1-seanjc@google.com/
[6] https://github.com/intel/vbh
[7] https://sched.co/TmwN
[8] https://sched.co/eE3f
[9] https://lore.kernel.org/all/20200501185147.208192-1-yuanyu@google.com/
[10] https://sched.co/eE4F
[11] https://lore.kernel.org/kvm/20191003212400.31130-1-rick.p.edgecombe@intel.com/
[12] https://lpc.events/event/4/contributions/283/
[13] https://sched.co/eE24

Please reach out to us by replying to this thread, we're looking for
people to join and collaborate on this project!

Previous version:
v1: https://lore.kernel.org/r/20230505152046.6575-1-mic@digikod.net

Regards,

Madhavan T. Venkataraman (9):
  virt: Introduce Hypervisor Enforced Kernel Integrity (Heki)
  KVM: x86: Add new hypercall to set EPT permissions
  x86: Implement the Memory Table feature to store arbitrary per-page
    data
  heki: Implement a kernel page table walker
  heki: x86: Initialize permissions counters for pages mapped into KVA
  heki: x86: Initialize permissions counters for pages in
    vmap()/vunmap()
  heki: x86: Update permissions counters when guest page permissions
    change
  heki: x86: Update permissions counters during text patching
  heki: x86: Protect guest kernel memory using the KVM hypervisor

Mickaël Salaün (10):
  KVM: x86: Add new hypercall to lock control registers
  KVM: x86: Add notifications for Heki policy configuration and
    violation
  heki: Lock guest control registers at the end of guest kernel init
  KVM: VMX: Add MBEC support
  KVM: x86: Add kvm_x86_ops.fault_gva()
  KVM: x86: Make memory attribute helpers more generic
  KVM: x86: Extend kvm_vm_set_mem_attributes() with a mask
  KVM: x86: Extend kvm_range_has_memory_attributes() with match_all
  KVM: x86: Implement per-guest-page permissions
  virt: Add Heki KUnit tests

 Documentation/virt/kvm/x86/hypercalls.rst |  31 +++
 Kconfig                                   |   2 +
 arch/x86/Kconfig                          |   1 +
 arch/x86/include/asm/kvm-x86-ops.h        |   1 +
 arch/x86/include/asm/kvm_host.h           |   2 +
 arch/x86/include/asm/vmx.h                |  11 +-
 arch/x86/include/asm/x86_init.h           |   1 +
 arch/x86/include/uapi/asm/kvm_para.h      |   2 +
 arch/x86/kernel/alternative.c             |   5 +
 arch/x86/kernel/cpu/common.c              |   4 +-
 arch/x86/kernel/cpu/hypervisor.c          |   1 +
 arch/x86/kernel/kvm.c                     |  67 +++++
 arch/x86/kernel/setup.c                   |   2 +
 arch/x86/kvm/Kconfig                      |   2 +
 arch/x86/kvm/Makefile                     |   4 +-
 arch/x86/kvm/mmu.h                        |   3 +-
 arch/x86/kvm/mmu/mmu.c                    | 114 ++++++--
 arch/x86/kvm/mmu/mmutrace.h               |  11 +-
 arch/x86/kvm/mmu/paging_tmpl.h            |  19 +-
 arch/x86/kvm/mmu/spte.c                   |  19 +-
 arch/x86/kvm/mmu/spte.h                   |  15 +-
 arch/x86/kvm/svm/svm.c                    |   9 +
 arch/x86/kvm/vmx/capabilities.h           |   7 +
 arch/x86/kvm/vmx/nested.c                 |   7 +
 arch/x86/kvm/vmx/vmx.c                    |  45 +++-
 arch/x86/kvm/vmx/vmx.h                    |   1 +
 arch/x86/kvm/x86.c                        | 310 ++++++++++++++++++++++
 arch/x86/kvm/x86.h                        |  23 ++
 arch/x86/mm/Makefile                      |   2 +
 arch/x86/mm/heki.c                        | 135 ++++++++++
 arch/x86/mm/pat/set_memory.c              |  51 ++++
 include/linux/heki.h                      | 195 ++++++++++++++
 include/linux/kvm_host.h                  |  11 +-
 include/linux/kvm_mem_attr.h              |  32 +++
 include/linux/mem_table.h                 |  55 ++++
 include/uapi/linux/kvm.h                  |  27 ++
 include/uapi/linux/kvm_para.h             |   2 +
 init/main.c                               |   3 +
 kernel/Makefile                           |   2 +
 kernel/mem_table.c                        | 219 +++++++++++++++
 mm/mm_init.c                              |   1 +
 mm/vmalloc.c                              |   7 +
 virt/Makefile                             |   1 +
 virt/heki/Kconfig                         |  42 +++
 virt/heki/Makefile                        |   6 +
 virt/heki/common.h                        |  16 ++
 virt/heki/counters.c                      | 274 +++++++++++++++++++
 virt/heki/main.c                          | 155 +++++++++++
 virt/heki/tests.c                         | 207 +++++++++++++++
 virt/heki/walk.c                          | 140 ++++++++++
 virt/kvm/kvm_main.c                       |  65 +++--
 virt/lib/kvm_permissions.c                | 104 ++++++++
 52 files changed, 2401 insertions(+), 70 deletions(-)
 create mode 100644 arch/x86/mm/heki.c
 create mode 100644 include/linux/heki.h
 create mode 100644 include/linux/kvm_mem_attr.h
 create mode 100644 include/linux/mem_table.h
 create mode 100644 kernel/mem_table.c
 create mode 100644 virt/heki/Kconfig
 create mode 100644 virt/heki/Makefile
 create mode 100644 virt/heki/common.h
 create mode 100644 virt/heki/counters.c
 create mode 100644 virt/heki/main.c
 create mode 100644 virt/heki/tests.c
 create mode 100644 virt/heki/walk.c
 create mode 100644 virt/lib/kvm_permissions.c


base-commit: 881375a408c0f4ea451ff14545b59216d2923881
-- 
2.42.1


^ permalink raw reply	[flat|nested] 44+ messages in thread
* Re: [RFC PATCH v2 14/19] heki: x86: Initialize permissions counters for pages mapped into KVA
  2023-11-13  2:23 ` [RFC PATCH v2 14/19] heki: x86: Initialize permissions counters for pages mapped into KVA Mickaël Salaün
@ 2023-11-14  1:22 ` kernel test robot
  -1 siblings, 0 replies; 44+ messages in thread
From: kernel test robot @ 2023-11-13  5:18 UTC (permalink / raw)
  To: oe-kbuild; +Cc: lkp

:::::: 
:::::: Manual check reason: "fbc 5dc2a03f8c532db0c352fd8cc08cefd8cbae43e6 and parent 44ac2f6f2e17897d27676ba4e80879929a1af167 have different kconfig"
:::::: Manual check reason: "has kconfig file changed"
:::::: 

BCC: lkp@intel.com
CC: oe-kbuild-all@lists.linux.dev
In-Reply-To: <20231113022326.24388-15-mic@digikod.net>
References: <20231113022326.24388-15-mic@digikod.net>
TO: "Mickaël Salaün" <mic@digikod.net>

Hi Mickaël,

[This is a private test report for your RFC patch.]
kernel test robot noticed the following build errors:

[auto build test ERROR on 881375a408c0f4ea451ff14545b59216d2923881]

url:    https://github.com/intel-lab-lkp/linux/commits/Micka-l-Sala-n/virt-Introduce-Hypervisor-Enforced-Kernel-Integrity-Heki/20231113-102847
base:   881375a408c0f4ea451ff14545b59216d2923881
patch link:    https://lore.kernel.org/r/20231113022326.24388-15-mic%40digikod.net
patch subject: [RFC PATCH v2 14/19] heki: x86: Initialize permissions counters for pages mapped into KVA
:::::: branch date: 3 hours ago
:::::: commit date: 3 hours ago
config: openrisc-allmodconfig (https://download.01.org/0day-ci/archive/20231113/202311131254.C8WZC0U9-lkp@intel.com/config)
compiler: or1k-linux-gcc (GCC) 13.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231113/202311131254.C8WZC0U9-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/r/202311131254.C8WZC0U9-lkp@intel.com/

All errors (new ones prefixed by >>):

   WARNING: unmet direct dependencies detected for SPARSEMEM
   Depends on [n]: !SELECT_MEMORY_MODEL [=n] && ARCH_SPARSEMEM_ENABLE || SPARSEMEM_MANUAL [=n]
   Selected by [y]:
   - HEKI [=y] && ARCH_SUPPORTS_HEKI [=y] && HYPERVISOR_SUPPORTS_HEKI [=y] && !X86_16BIT
   In file included from include/linux/mm_types.h:18,
   from include/linux/sched/signal.h:13,
   from include/linux/ptrace.h:7,
   from arch/openrisc/kernel/asm-offsets.c:28:
>> include/linux/page-flags-layout.h:30:10: fatal error: asm/sparsemem.h: No such file or directory
   30 | #include <asm/sparsemem.h>
   |          ^~~~~~~~~~~~~~~~~
   compilation terminated.
   make[3]: *** [scripts/Makefile.build:116: arch/openrisc/kernel/asm-offsets.s] Error 1
   make[3]: Target 'prepare' not remade because of errors.
   make[2]: *** [Makefile:1202: prepare0] Error 2
   make[2]: Target 'prepare' not remade because of errors.
   make[1]: *** [Makefile:234: __sub-make] Error 2
   make[1]: Target 'prepare' not remade because of errors.
   make: *** [Makefile:234: __sub-make] Error 2
   make: Target 'prepare' not remade because of errors.

Kconfig warnings: (for reference only)
   WARNING: unmet direct dependencies detected for SPARSEMEM
   Depends on [n]: !SELECT_MEMORY_MODEL [=n] && ARCH_SPARSEMEM_ENABLE || SPARSEMEM_MANUAL [=n]
   Selected by [y]:
   - HEKI [=y] && ARCH_SUPPORTS_HEKI [=y] && HYPERVISOR_SUPPORTS_HEKI [=y] && !X86_16BIT


vim +30 include/linux/page-flags-layout.h

1587db62d8c0db Yu Zhao        2021-04-29  28  
bbeae5b05ef6e4 Peter Zijlstra 2013-02-22  29  #ifdef CONFIG_SPARSEMEM
bbeae5b05ef6e4 Peter Zijlstra 2013-02-22 @30  #include <asm/sparsemem.h>
bbeae5b05ef6e4 Peter Zijlstra 2013-02-22  31  #define SECTIONS_SHIFT	(MAX_PHYSMEM_BITS - SECTION_SIZE_BITS)
1587db62d8c0db Yu Zhao        2021-04-29  32  #else
1587db62d8c0db Yu Zhao        2021-04-29  33  #define SECTIONS_SHIFT	0
1587db62d8c0db Yu Zhao        2021-04-29  34  #endif
bbeae5b05ef6e4 Peter Zijlstra 2013-02-22  35  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

^ permalink raw reply	[flat|nested] 44+ messages in thread
* Re: [RFC PATCH v2 10/19] KVM: x86: Implement per-guest-page permissions
  2023-11-13  2:23 ` [RFC PATCH v2 10/19] KVM: x86: Implement per-guest-page permissions Mickaël Salaün
@ 2023-11-14  1:27 ` kernel test robot
  -1 siblings, 0 replies; 44+ messages in thread
From: kernel test robot @ 2023-11-13  7:42 UTC (permalink / raw)
  To: oe-kbuild; +Cc: lkp

:::::: 
:::::: Manual check reason: "fbc e677181e18929a5506e046fcb60f660060216505 and parent dd628ea6472ca6fefaaa3d84baab96270832e7e8 have different kconfig"
:::::: Manual check reason: "has kconfig file changed"
:::::: 

BCC: lkp@intel.com
CC: oe-kbuild-all@lists.linux.dev
In-Reply-To: <20231113022326.24388-11-mic@digikod.net>
References: <20231113022326.24388-11-mic@digikod.net>
TO: "Mickaël Salaün" <mic@digikod.net>

Hi Mickaël,

[This is a private test report for your RFC patch.]
kernel test robot noticed the following build errors:

[auto build test ERROR on 881375a408c0f4ea451ff14545b59216d2923881]

url:    https://github.com/intel-lab-lkp/linux/commits/Micka-l-Sala-n/virt-Introduce-Hypervisor-Enforced-Kernel-Integrity-Heki/20231113-102847
base:   881375a408c0f4ea451ff14545b59216d2923881
patch link:    https://lore.kernel.org/r/20231113022326.24388-11-mic%40digikod.net
patch subject: [RFC PATCH v2 10/19] KVM: x86: Implement per-guest-page permissions
:::::: branch date: 5 hours ago
:::::: commit date: 5 hours ago
config: i386-randconfig-002-20231113 (https://download.01.org/0day-ci/archive/20231113/202311131527.nBtS1Ewn-lkp@intel.com/config)
compiler: gcc-12 (Debian 12.2.0-14) 12.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231113/202311131527.nBtS1Ewn-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/r/202311131527.nBtS1Ewn-lkp@intel.com/

All errors (new ones prefixed by >>):

   WARNING: unmet direct dependencies detected for SPARSEMEM
   Depends on [n]: !SELECT_MEMORY_MODEL [=y] && ARCH_SPARSEMEM_ENABLE [=y] || SPARSEMEM_MANUAL [=n]
   Selected by [y]:
   - KVM [=y] && VIRTUALIZATION [=y] && HAVE_KVM [=y] && HIGH_RES_TIMERS [=y] && X86_LOCAL_APIC [=y]
   In file included from arch/x86/include/asm/page.h:85,
   from arch/x86/include/asm/thread_info.h:12,
   from include/linux/thread_info.h:60,
   from arch/x86/include/asm/preempt.h:9,
   from include/linux/preempt.h:79,
   from include/linux/spinlock.h:56,
   from include/linux/swait.h:7,
   from include/linux/completion.h:12,
   from include/linux/crypto.h:15,
   from arch/x86/kernel/asm-offsets.c:9:
>> include/asm-generic/memory_model.h:31:19: error: redefinition of 'pfn_valid'
   31 | #define pfn_valid pfn_valid
   |                   ^~~~~~~~~
   include/linux/mmzone.h:1987:19: note: in expansion of macro 'pfn_valid'
   1987 | static inline int pfn_valid(unsigned long pfn)
   |                   ^~~~~~~~~
   include/asm-generic/memory_model.h:23:19: note: previous definition of 'pfn_valid' with type 'int(long unsigned int)'
   23 | static inline int pfn_valid(unsigned long pfn)
   |                   ^~~~~~~~~
   make[3]: *** [scripts/Makefile.build:116: arch/x86/kernel/asm-offsets.s] Error 1 shuffle=912718013
   make[3]: Target 'prepare' not remade because of errors.
   make[2]: *** [Makefile:1202: prepare0] Error 2 shuffle=912718013
   make[2]: Target 'prepare' not remade because of errors.
   make[1]: *** [Makefile:234: __sub-make] Error 2 shuffle=912718013
   make[1]: Target 'prepare' not remade because of errors.
   make: *** [Makefile:234: __sub-make] Error 2 shuffle=912718013
   make: Target 'prepare' not remade because of errors.

Kconfig warnings: (for reference only)
   WARNING: unmet direct dependencies detected for SPARSEMEM
   Depends on [n]: !SELECT_MEMORY_MODEL [=y] && ARCH_SPARSEMEM_ENABLE [=y] || SPARSEMEM_MANUAL [=n]
   Selected by [y]:
   - KVM [=y] && VIRTUALIZATION [=y] && HAVE_KVM [=y] && HIGH_RES_TIMERS [=y] && X86_LOCAL_APIC [=y]


vim +/pfn_valid +31 include/asm-generic/memory_model.h

a117e66ed45ac0 KAMEZAWA Hiroyuki   2006-03-27  17  
67de648211fa04 Andy Whitcroft      2006-06-23  18  #define __pfn_to_page(pfn)	(mem_map + ((pfn) - ARCH_PFN_OFFSET))
67de648211fa04 Andy Whitcroft      2006-06-23  19  #define __page_to_pfn(page)	((unsigned long)((page) - mem_map) + \
a117e66ed45ac0 KAMEZAWA Hiroyuki   2006-03-27  20  				 ARCH_PFN_OFFSET)
a117e66ed45ac0 KAMEZAWA Hiroyuki   2006-03-27  21  
e5080a9677854b Mike Rapoport (IBM  2023-01-29  22) #ifndef pfn_valid
e5080a9677854b Mike Rapoport (IBM  2023-01-29  23) static inline int pfn_valid(unsigned long pfn)
e5080a9677854b Mike Rapoport (IBM  2023-01-29  24) {
e5080a9677854b Mike Rapoport (IBM  2023-01-29  25) 	/* avoid <linux/mm.h> include hell */
e5080a9677854b Mike Rapoport (IBM  2023-01-29  26) 	extern unsigned long max_mapnr;
e5080a9677854b Mike Rapoport (IBM  2023-01-29  27) 	unsigned long pfn_offset = ARCH_PFN_OFFSET;
e5080a9677854b Mike Rapoport (IBM  2023-01-29  28) 
e5080a9677854b Mike Rapoport (IBM  2023-01-29  29) 	return pfn >= pfn_offset && (pfn - pfn_offset) < max_mapnr;
e5080a9677854b Mike Rapoport (IBM  2023-01-29  30) }
e5080a9677854b Mike Rapoport (IBM  2023-01-29 @31) #define pfn_valid pfn_valid
e5080a9677854b Mike Rapoport (IBM  2023-01-29  32) #endif
e5080a9677854b Mike Rapoport (IBM  2023-01-29  33) 

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

^ permalink raw reply	[flat|nested] 44+ messages in thread
* Re: [RFC PATCH v2 18/19] heki: x86: Protect guest kernel memory using the KVM hypervisor
  2023-11-13  2:23 ` [RFC PATCH v2 18/19] heki: x86: Protect guest kernel memory using the KVM hypervisor Mickaël Salaün
@ 2023-11-14  1:30 ` kernel test robot
  0 siblings, 0 replies; 44+ messages in thread
From: kernel test robot @ 2023-11-13  8:14 UTC (permalink / raw)
  To: oe-kbuild; +Cc: lkp

:::::: 
:::::: Manual check reason: "has kconfig file changed"
:::::: 

BCC: lkp@intel.com
CC: oe-kbuild-all@lists.linux.dev
In-Reply-To: <20231113022326.24388-19-mic@digikod.net>
References: <20231113022326.24388-19-mic@digikod.net>
TO: "Mickaël Salaün" <mic@digikod.net>

Hi Mickaël,

[This is a private test report for your RFC patch.]
kernel test robot noticed the following build errors:

[auto build test ERROR on 881375a408c0f4ea451ff14545b59216d2923881]

url:    https://github.com/intel-lab-lkp/linux/commits/Micka-l-Sala-n/virt-Introduce-Hypervisor-Enforced-Kernel-Integrity-Heki/20231113-102847
base:   881375a408c0f4ea451ff14545b59216d2923881
patch link:    https://lore.kernel.org/r/20231113022326.24388-19-mic%40digikod.net
patch subject: [RFC PATCH v2 18/19] heki: x86: Protect guest kernel memory using the KVM hypervisor
:::::: branch date: 6 hours ago
:::::: commit date: 6 hours ago
config: riscv-randconfig-001-20231113 (attached as .config)
compiler: riscv64-linux-gcc (GCC) 13.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231113/202311131528.mJpddiq3-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/r/202311131528.mJpddiq3-lkp@intel.com/

All errors (new ones prefixed by >>):

>> arch/riscv/Kconfig:833:error: recursive dependency detected!
   arch/riscv/Kconfig:833:	symbol XIP_KERNEL depends on SPARSEMEM
   mm/Kconfig:461:	symbol SPARSEMEM is selected by HEKI
   virt/heki/Kconfig:5:	symbol HEKI depends on JUMP_LABEL
   arch/Kconfig:66:	symbol JUMP_LABEL depends on HAVE_ARCH_JUMP_LABEL
   arch/Kconfig:441:	symbol HAVE_ARCH_JUMP_LABEL is selected by XIP_KERNEL
   For a resolution refer to Documentation/kbuild/kconfig-language.rst
   subsection "Kconfig recursive dependency limitations"


vim +833 arch/riscv/Kconfig

aef53f97b505ff Nick Kossifidis 2018-09-20  787  
d7071743db31b4 Atish Patra     2020-09-17  788  config EFI_STUB
d7071743db31b4 Atish Patra     2020-09-17  789  	bool
d7071743db31b4 Atish Patra     2020-09-17  790  
d7071743db31b4 Atish Patra     2020-09-17  791  config EFI
d7071743db31b4 Atish Patra     2020-09-17  792  	bool "UEFI runtime support"
44c922572952d8 Vitaly Wool     2021-04-13  793  	depends on OF && !XIP_KERNEL
5f365c133b83a5 Conor Dooley    2022-12-19  794  	depends on MMU
5f365c133b83a5 Conor Dooley    2022-12-19  795  	default y
a91a9ffbd3a55a Sunil V L       2023-05-15  796  	select ARCH_SUPPORTS_ACPI if 64BIT
d7071743db31b4 Atish Patra     2020-09-17  797  	select EFI_GENERIC_STUB
5f365c133b83a5 Conor Dooley    2022-12-19  798  	select EFI_PARAMS_FROM_FDT
b91540d52a08b6 Atish Patra     2020-09-17  799  	select EFI_RUNTIME_WRAPPERS
5f365c133b83a5 Conor Dooley    2022-12-19  800  	select EFI_STUB
5f365c133b83a5 Conor Dooley    2022-12-19  801  	select LIBFDT
d7071743db31b4 Atish Patra     2020-09-17  802  	select RISCV_ISA_C
5f365c133b83a5 Conor Dooley    2022-12-19  803  	select UCS2_STRING
d7071743db31b4 Atish Patra     2020-09-17  804  	help
d7071743db31b4 Atish Patra     2020-09-17  805  	  This option provides support for runtime services provided
d7071743db31b4 Atish Patra     2020-09-17  806  	  by UEFI firmware (such as non-volatile variables, realtime
d7071743db31b4 Atish Patra     2020-09-17  807  	  clock, and platform reset). A UEFI stub is also provided to
d7071743db31b4 Atish Patra     2020-09-17  808  	  allow the kernel to be booted as an EFI application. This
d7071743db31b4 Atish Patra     2020-09-17  809  	  is only useful on systems that have UEFI firmware.
d7071743db31b4 Atish Patra     2020-09-17  810  
fea2fed201ee56 Guo Ren         2020-12-17  811  config CC_HAVE_STACKPROTECTOR_TLS
fea2fed201ee56 Guo Ren         2020-12-17  812  	def_bool $(cc-option,-mstack-protector-guard=tls -mstack-protector-guard-reg=tp -mstack-protector-guard-offset=0)
fea2fed201ee56 Guo Ren         2020-12-17  813  
fea2fed201ee56 Guo Ren         2020-12-17  814  config STACKPROTECTOR_PER_TASK
fea2fed201ee56 Guo Ren         2020-12-17  815  	def_bool y
595b893e2087de Kees Cook       2022-05-03  816  	depends on !RANDSTRUCT
fea2fed201ee56 Guo Ren         2020-12-17  817  	depends on STACKPROTECTOR && CC_HAVE_STACKPROTECTOR_TLS
fea2fed201ee56 Guo Ren         2020-12-17  818  
867432bec1c6e7 Alexandre Ghiti 2021-07-21  819  config PHYS_RAM_BASE_FIXED
867432bec1c6e7 Alexandre Ghiti 2021-07-21  820  	bool "Explicitly specified physical RAM address"
44c1e84a38a031 Palmer Dabbelt  2022-05-21  821  	depends on NONPORTABLE
867432bec1c6e7 Alexandre Ghiti 2021-07-21  822  	default n
867432bec1c6e7 Alexandre Ghiti 2021-07-21  823  
44c922572952d8 Vitaly Wool     2021-04-13  824  config PHYS_RAM_BASE
44c922572952d8 Vitaly Wool     2021-04-13  825  	hex "Platform Physical RAM address"
867432bec1c6e7 Alexandre Ghiti 2021-07-21  826  	depends on PHYS_RAM_BASE_FIXED
44c922572952d8 Vitaly Wool     2021-04-13  827  	default "0x80000000"
44c922572952d8 Vitaly Wool     2021-04-13  828  	help
44c922572952d8 Vitaly Wool     2021-04-13  829  	  This is the physical address of RAM in the system. It has to be
44c922572952d8 Vitaly Wool     2021-04-13  830  	  explicitly specified to run early relocations of read-write data
44c922572952d8 Vitaly Wool     2021-04-13  831  	  from flash to RAM.
44c922572952d8 Vitaly Wool     2021-04-13  832  
44c922572952d8 Vitaly Wool     2021-04-13 @833  config XIP_KERNEL
44c922572952d8 Vitaly Wool     2021-04-13  834  	bool "Kernel Execute-In-Place from ROM"
44c1e84a38a031 Palmer Dabbelt  2022-05-21  835  	depends on MMU && SPARSEMEM && NONPORTABLE
44c922572952d8 Vitaly Wool     2021-04-13  836  	# This prevents XIP from being enabled by all{yes,mod}config, which
44c922572952d8 Vitaly Wool     2021-04-13  837  	# fail to build since XIP doesn't support large kernels.
44c922572952d8 Vitaly Wool     2021-04-13  838  	depends on !COMPILE_TEST
867432bec1c6e7 Alexandre Ghiti 2021-07-21  839  	select PHYS_RAM_BASE_FIXED
44c922572952d8 Vitaly Wool     2021-04-13  840  	help
44c922572952d8 Vitaly Wool     2021-04-13  841  	  Execute-In-Place allows the kernel to run from non-volatile storage
44c922572952d8 Vitaly Wool     2021-04-13  842  	  directly addressable by the CPU, such as NOR flash. This saves RAM
44c922572952d8 Vitaly Wool     2021-04-13  843  	  space since the text section of the kernel is not loaded from flash
44c922572952d8 Vitaly Wool     2021-04-13  844  	  to RAM.  Read-write sections, such as the data section and stack,
44c922572952d8 Vitaly Wool     2021-04-13  845  	  are still copied to RAM.  The XIP kernel is not compressed since
44c922572952d8 Vitaly Wool     2021-04-13  846  	  it has to run directly from flash, so it will take more space to
44c922572952d8 Vitaly Wool     2021-04-13  847  	  store it.  The flash address used to link the kernel object files,
44c922572952d8 Vitaly Wool     2021-04-13  848  	  and for storing it, is configuration dependent. Therefore, if you
44c922572952d8 Vitaly Wool     2021-04-13  849  	  say Y here, you must know the proper physical address where to
44c922572952d8 Vitaly Wool     2021-04-13  850  	  store the kernel image depending on your own flash memory usage.
44c922572952d8 Vitaly Wool     2021-04-13  851  
44c922572952d8 Vitaly Wool     2021-04-13  852  	  Also note that the make target becomes "make xipImage" rather than
44c922572952d8 Vitaly Wool     2021-04-13  853  	  "make zImage" or "make Image".  The final kernel binary to put in
44c922572952d8 Vitaly Wool     2021-04-13  854  	  ROM memory will be arch/riscv/boot/xipImage.
44c922572952d8 Vitaly Wool     2021-04-13  855  
44c922572952d8 Vitaly Wool     2021-04-13  856  	  SPARSEMEM is required because the kernel text and rodata that are
44c922572952d8 Vitaly Wool     2021-04-13  857  	  flash resident are not backed by memmap, then any attempt to get
44c922572952d8 Vitaly Wool     2021-04-13  858  	  a struct page on those regions will trigger a fault.
44c922572952d8 Vitaly Wool     2021-04-13  859  
44c922572952d8 Vitaly Wool     2021-04-13  860  	  If unsure, say N.
44c922572952d8 Vitaly Wool     2021-04-13  861  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

^ permalink raw reply	[flat|nested] 44+ messages in thread
* Re: [RFC PATCH v2 10/19] KVM: x86: Implement per-guest-page permissions
  2023-11-13  2:23 ` [RFC PATCH v2 10/19] KVM: x86: Implement per-guest-page permissions Mickaël Salaün
@ 2023-11-14  1:29 ` kernel test robot
  -1 siblings, 0 replies; 44+ messages in thread
From: kernel test robot @ 2023-11-13 12:37 UTC (permalink / raw)
  To: oe-kbuild; +Cc: lkp

:::::: 
:::::: Manual check reason: "has kconfig file changed"
:::::: 

BCC: lkp@intel.com
CC: oe-kbuild-all@lists.linux.dev
In-Reply-To: <20231113022326.24388-11-mic@digikod.net>
References: <20231113022326.24388-11-mic@digikod.net>
TO: "Mickaël Salaün" <mic@digikod.net>

Hi Mickaël,

[This is a private test report for your RFC patch.]
kernel test robot noticed the following build errors:

[auto build test ERROR on 881375a408c0f4ea451ff14545b59216d2923881]

url:    https://github.com/intel-lab-lkp/linux/commits/Micka-l-Sala-n/virt-Introduce-Hypervisor-Enforced-Kernel-Integrity-Heki/20231113-102847
base:   881375a408c0f4ea451ff14545b59216d2923881
patch link:    https://lore.kernel.org/r/20231113022326.24388-11-mic%40digikod.net
patch subject: [RFC PATCH v2 10/19] KVM: x86: Implement per-guest-page permissions
:::::: branch date: 10 hours ago
:::::: commit date: 10 hours ago
config: x86_64-randconfig-013-20231113 (https://download.01.org/0day-ci/archive/20231113/202311132003.c5QKfbEI-lkp@intel.com/config)
compiler: gcc-12 (Debian 12.2.0-14) 12.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231113/202311132003.c5QKfbEI-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/r/202311132003.c5QKfbEI-lkp@intel.com/

All errors (new ones prefixed by >>):

   arch/x86/kvm/../../../virt/lib/kvm_permissions.c: In function 'kvm_permissions_get':
>> arch/x86/kvm/../../../virt/lib/kvm_permissions.c:74:20: error: implicit declaration of function 'kvm_get_memory_attributes' [-Werror=implicit-function-declaration]
      74 |         kvm_attr = kvm_get_memory_attributes(kvm, gfn);
         |                    ^~~~~~~~~~~~~~~~~~~~~~~~~
   arch/x86/kvm/../../../virt/lib/kvm_permissions.c: In function 'kvm_permissions_set':
>> arch/x86/kvm/../../../virt/lib/kvm_permissions.c:91:13: error: implicit declaration of function 'kvm_range_has_memory_attributes'; did you mean 'kvm_mmu_init_memslot_memory_attributes'? [-Werror=implicit-function-declaration]
      91 |         if (kvm_range_has_memory_attributes(kvm, gfn_start, gfn_end,
         |             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
         |             kvm_mmu_init_memslot_memory_attributes
>> arch/x86/kvm/../../../virt/lib/kvm_permissions.c:100:16: error: implicit declaration of function 'kvm_vm_set_mem_attributes' [-Werror=implicit-function-declaration]
     100 |         return kvm_vm_set_mem_attributes(kvm, gfn_start, gfn_end,
         |                ^~~~~~~~~~~~~~~~~~~~~~~~~
   cc1: some warnings being treated as errors


vim +/kvm_get_memory_attributes +74 arch/x86/kvm/../../../virt/lib/kvm_permissions.c

e677181e18929a Mickaël Salaün 2023-11-12   63  
e677181e18929a Mickaël Salaün 2023-11-12   64  unsigned long kvm_permissions_get(struct kvm *kvm, gfn_t gfn)
e677181e18929a Mickaël Salaün 2023-11-12   65  {
e677181e18929a Mickaël Salaün 2023-11-12   66  	unsigned long kvm_attr = 0;
e677181e18929a Mickaël Salaün 2023-11-12   67  
e677181e18929a Mickaël Salaün 2023-11-12   68  	/*
e677181e18929a Mickaël Salaün 2023-11-12   69  	 * Retrieve the permissions for a guest page. If not present (i.e., no
e677181e18929a Mickaël Salaün 2023-11-12   70  	 * attribute), then return default permissions (RWX).  This means
e677181e18929a Mickaël Salaün 2023-11-12   71  	 * setting permissions to 0 resets them to RWX. We might want to
e677181e18929a Mickaël Salaün 2023-11-12   72  	 * revisit that in a future version.
e677181e18929a Mickaël Salaün 2023-11-12   73  	 */
e677181e18929a Mickaël Salaün 2023-11-12  @74  	kvm_attr = kvm_get_memory_attributes(kvm, gfn);
e677181e18929a Mickaël Salaün 2023-11-12   75  	if (kvm_attr)
e677181e18929a Mickaël Salaün 2023-11-12   76  		return kvm_attr_to_heki_attr(kvm_attr);
e677181e18929a Mickaël Salaün 2023-11-12   77  	else
e677181e18929a Mickaël Salaün 2023-11-12   78  		return kvm_default_permissions;
e677181e18929a Mickaël Salaün 2023-11-12   79  }
e677181e18929a Mickaël Salaün 2023-11-12   80  EXPORT_SYMBOL_GPL(kvm_permissions_get);
e677181e18929a Mickaël Salaün 2023-11-12   81  
e677181e18929a Mickaël Salaün 2023-11-12   82  int kvm_permissions_set(struct kvm *kvm, gfn_t gfn_start, gfn_t gfn_end,
e677181e18929a Mickaël Salaün 2023-11-12   83  			unsigned long heki_attr)
e677181e18929a Mickaël Salaün 2023-11-12   84  {
e677181e18929a Mickaël Salaün 2023-11-12   85  	if ((heki_attr | MEM_ATTR_PROT) != MEM_ATTR_PROT)
e677181e18929a Mickaël Salaün 2023-11-12   86  		return -EINVAL;
e677181e18929a Mickaël Salaün 2023-11-12   87  
e677181e18929a Mickaël Salaün 2023-11-12   88  	if (gfn_end <= gfn_start)
e677181e18929a Mickaël Salaün 2023-11-12   89  		return -EINVAL;
e677181e18929a Mickaël Salaün 2023-11-12   90  
e677181e18929a Mickaël Salaün 2023-11-12  @91  	if (kvm_range_has_memory_attributes(kvm, gfn_start, gfn_end,
e677181e18929a Mickaël Salaün 2023-11-12   92  					    KVM_MEMORY_ATTRIBUTE_HEKI_IMMUTABLE,
e677181e18929a Mickaël Salaün 2023-11-12   93  					    false)) {
e677181e18929a Mickaël Salaün 2023-11-12   94  		pr_warn_ratelimited(
e677181e18929a Mickaël Salaün 2023-11-12   95  			"Guest tried to change immutable permission for GFNs %llx-%llx\n",
e677181e18929a Mickaël Salaün 2023-11-12   96  			gfn_start, gfn_end);
e677181e18929a Mickaël Salaün 2023-11-12   97  		return -EPERM;
e677181e18929a Mickaël Salaün 2023-11-12   98  	}
e677181e18929a Mickaël Salaün 2023-11-12   99  
e677181e18929a Mickaël Salaün 2023-11-12 @100  	return kvm_vm_set_mem_attributes(kvm, gfn_start, gfn_end,

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

^ permalink raw reply	[flat|nested] 44+ messages in thread
end of thread, other threads:[~2023-12-08 18:41 UTC | newest]

Thread overview: 44+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-11-13  2:23 [RFC PATCH v2 00/19] Hypervisor-Enforced Kernel Integrity Mickaël Salaün
2023-11-13  2:23 ` [RFC PATCH v2 01/19] virt: Introduce Hypervisor Enforced Kernel Integrity (Heki) Mickaël Salaün
2023-11-13  2:23 ` [RFC PATCH v2 02/19] KVM: x86: Add new hypercall to lock control registers Mickaël Salaün
2023-11-13  2:23 ` [RFC PATCH v2 03/19] KVM: x86: Add notifications for Heki policy configuration and violation Mickaël Salaün
2023-11-13  2:23 ` [RFC PATCH v2 04/19] heki: Lock guest control registers at the end of guest kernel init Mickaël Salaün
2023-11-13  2:23 ` [RFC PATCH v2 05/19] KVM: VMX: Add MBEC support Mickaël Salaün
2023-11-13  2:23 ` [RFC PATCH v2 06/19] KVM: x86: Add kvm_x86_ops.fault_gva() Mickaël Salaün
2023-11-13  2:23 ` [RFC PATCH v2 07/19] KVM: x86: Make memory attribute helpers more generic Mickaël Salaün
2023-11-13  2:23 ` [RFC PATCH v2 08/19] KVM: x86: Extend kvm_vm_set_mem_attributes() with a mask Mickaël Salaün
2023-11-13  2:23 ` [RFC PATCH v2 09/19] KVM: x86: Extend kvm_range_has_memory_attributes() with match_all Mickaël Salaün
2023-11-13  2:23 ` [RFC PATCH v2 10/19] KVM: x86: Implement per-guest-page permissions Mickaël Salaün
2023-11-13  2:23 ` [RFC PATCH v2 11/19] KVM: x86: Add new hypercall to set EPT permissions Mickaël Salaün
2023-11-13  4:45   ` kernel test robot
2023-11-13  2:23 ` [RFC PATCH v2 12/19] x86: Implement the Memory Table feature to store arbitrary per-page data Mickaël Salaün
2023-11-22  7:19   ` kernel test robot
2023-11-13  2:23 ` [RFC PATCH v2 13/19] heki: Implement a kernel page table walker Mickaël Salaün
2023-11-13  2:23 ` [RFC PATCH v2 14/19] heki: x86: Initialize permissions counters for pages mapped into KVA Mickaël Salaün
2023-11-13  2:23 ` [RFC PATCH v2 15/19] heki: x86: Initialize permissions counters for pages in vmap()/vunmap() Mickaël Salaün
2023-11-13  2:23 ` [RFC PATCH v2 16/19] heki: x86: Update permissions counters when guest page permissions change Mickaël Salaün
2023-11-13  2:23 ` [RFC PATCH v2 17/19] heki: x86: Update permissions counters during text patching Mickaël Salaün
2023-11-13  8:19   ` Peter Zijlstra
2023-11-27 16:48     ` Madhavan T. Venkataraman
2023-11-27 20:08       ` Peter Zijlstra
2023-11-29 21:07         ` Madhavan T. Venkataraman
2023-11-30 11:33           ` Peter Zijlstra
2023-12-06 16:37             ` Madhavan T. Venkataraman
2023-12-06 18:51               ` Peter Zijlstra
2023-12-08 18:41                 ` Madhavan T. Venkataraman
2023-12-01  0:45           ` Edgecombe, Rick P
2023-12-06 16:41             ` Madhavan T. Venkataraman
2023-11-13  2:23 ` [RFC PATCH v2 18/19] heki: x86: Protect guest kernel memory using the KVM hypervisor Mickaël Salaün
2023-11-13  8:54   ` Peter Zijlstra
2023-11-27 17:05     ` Madhavan T. Venkataraman
2023-11-27 20:03       ` Peter Zijlstra
2023-11-29 19:47         ` Madhavan T. Venkataraman
2023-11-13  2:23 ` [RFC PATCH v2 19/19] virt: Add Heki KUnit tests Mickaël Salaün
2023-11-13  5:18 [RFC PATCH v2 14/19] heki: x86: Initialize permissions counters for pages mapped into KVA kernel test robot
2023-11-14  1:22 ` kernel test robot
2023-11-13  7:42 [RFC PATCH v2 10/19] KVM: x86: Implement per-guest-page permissions kernel test robot
2023-11-14  1:27 ` kernel test robot
2023-11-13  8:14 [RFC PATCH v2 18/19] heki: x86: Protect guest kernel memory using the KVM hypervisor kernel test robot
2023-11-14  1:30 ` kernel test robot
2023-11-13 12:37 [RFC PATCH v2 10/19] KVM: x86: Implement per-guest-page permissions kernel test robot
2023-11-14  1:29 ` kernel test robot

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.