lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 13 Nov 2023 09:54:03 +0100
From: Peter Zijlstra <>
To: Mickaël Salaün <>
Cc: Borislav Petkov <>,
	Dave Hansen <>,
	"H . Peter Anvin" <>, Ingo Molnar <>,
	Kees Cook <>,
	Paolo Bonzini <>,
	Sean Christopherson <>,
	Thomas Gleixner <>,
	Vitaly Kuznetsov <>,
	Wanpeng Li <>,
	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 <>,,,,,,,,,,
Subject: Re: [RFC PATCH v2 18/19] heki: x86: Protect guest kernel memory
 using the KVM hypervisor

On Sun, Nov 12, 2023 at 09:23:25PM -0500, Mickaël Salaün wrote:
> From: Madhavan T. Venkataraman <>
> Implement a hypervisor function, kvm_protect_memory() that calls the
> KVM_HC_PROTECT_MEMORY hypercall to request the KVM hypervisor to
> set specified permissions on a list of guest pages.
> Using the protect_memory() function, set proper EPT permissions for all
> guest pages.
> Use the MEM_ATTR_IMMUTABLE property to protect the kernel static
> sections and the boot-time read-only sections. This enables to make sure
> a compromised guest will not be able to change its main physical memory
> page permissions. However, this also disable any feature that may change
> the kernel's text section (e.g., ftrace, Kprobes), but they can still be
> used on kernel modules.
> Module loading/unloading, and eBPF JIT is allowed without restrictions
> for now, but we'll need a way to authenticate these code changes to
> really improve the guests' security. We plan to use module signatures,
> but there is no solution yet to authenticate eBPF programs.
> Being able to use ftrace and Kprobes in a secure way is a challenge not
> solved yet. We're looking for ideas to make this work.
> Likewise, the JUMP_LABEL feature cannot work because the kernel's text
> section is read-only.

What is the actual problem? As is the kernel text map is already RO and
never changed.

Powered by blists - more mailing lists