On 2019/1/7 下午12:23, Michael S. Tsirkin wrote:
On Mon, Jan 07, 2019 at 11:58:23AM +0800, Jason Wang wrote:
On 2019/1/3 上午4:57, Michael S. Tsirkin wrote:
It's not uncommon to have two access two unrelated memory locations in a
specific order. At the moment one has to use a memory barrier for
On Mon, Jan 07, 2019 at 11:58:23AM +0800, Jason Wang wrote:
>
> On 2019/1/3 上午4:57, Michael S. Tsirkin wrote:
> > It's not uncommon to have two access two unrelated memory locations in a
> > specific order. At the moment one has to use a memory barrier for this.
> >
> > However, if the first acc
On Sun, Jan 06 2019, Randy Dunlap wrote:
> From: Randy Dunlap
>
> Fix Sphinx warnings in path-lookup.rst:
>
> Documentation/filesystems/path-lookup.rst:347: WARNING: Title underline too
> short.
> Documentation/filesystems/path-lookup.rst:358: WARNING: Title underline too
> short.
> Documentati
On 2019/1/3 上午4:57, Michael S. Tsirkin wrote:
It's not uncommon to have two access two unrelated memory locations in a
specific order. At the moment one has to use a memory barrier for this.
However, if the first access was a read and the second used an address
depending on the first one we w
From: Randy Dunlap
Fix Sphinx warnings in path-lookup.rst:
Documentation/filesystems/path-lookup.rst:347: WARNING: Title underline too
short.
Documentation/filesystems/path-lookup.rst:358: WARNING: Title underline too
short.
Documentation/filesystems/path-lookup.rst:369: WARNING: Title underli
On 01/07/19 at 09:47am, Lianbo Jiang wrote:
> For AMD machine with SME feature, makedumpfile tools need to know
> whether the crash kernel was encrypted or not. If SME is enabled
^ crashed
> in the first kernel, the crash kernel's page table(pgd/pud/pmd/pte)
For AMD machine with SME feature, makedumpfile tools need to know
whether the crash kernel was encrypted or not. If SME is enabled
in the first kernel, the crash kernel's page table(pgd/pud/pmd/pte)
contains the memory encryption mask, so need to remove the sme mask
to obtain the true physical addr
This document lists some variables that export to vmcoreinfo, and briefly
describles what these variables indicate. It should be instructive for
many people who do not know the vmcoreinfo, and it also normalizes the
exported variables as a convention between kernel and use-space.
Suggested-by: Bor
This patchset did two things:
a. add a new document for vmcoreinfo
This document lists some variables that export to vmcoreinfo, and briefly
describles what these variables indicate. It should be instructive for
many people who do not know the vmcoreinfo, and it also normalizes the
exported variab
ROE version documented here is implemented in the next 2 patches
Signed-off-by: Ahmed Abd El Mawgood
---
Documentation/virtual/kvm/hypercalls.txt | 40
1 file changed, 40 insertions(+)
diff --git a/Documentation/virtual/kvm/hypercalls.txt
b/Documentation/virtual/kvm/hyp
This patch documents and implements ROE_MPROTECT_CHUNK, a part of ROE
hypercall designed to protect regions of a memory page with byte
granularity. This feature provides a key primitive to protect against
attacks involving pages remapping.
Signed-off-by: Ahmed Abd El Mawgood
---
include/linux/kv
Signed-off-by: Ahmed Abd El Mawgood
---
virt/kvm/kvm_main.c| 3 ++-
virt/kvm/roe.c | 25 +
virt/kvm/roe_generic.h | 3 ++-
3 files changed, 29 insertions(+), 2 deletions(-)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index d92d300539..b3dc7255b0 1
Apply d->memslot->partial_roe_bitmap to shadow page table entries
too.
Signed-off-by: Ahmed Abd El Mawgood
---
arch/x86/kvm/roe.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kvm/roe.c b/arch/x86/kvm/roe.c
index f787106be8..700f69823b 100644
--- a/arch/x86/kvm
The problem is that qemu will not be able to detect ROE violations, so
one option would be create host API to tell if a given page is ROE
protected, or create ROE violation exit reason.
Signed-off-by: Ahmed Abd El Mawgood
---
arch/x86/kvm/x86.c | 10 +-
include/kvm/roe.h| 1
This patch implements kvm_roe_arch_commit_protection and
kvm_roe_arch_is_userspace for x86, and invoke kvm_roe via the
appropriate vmcall.
Signed-off-by: Ahmed Abd El Mawgood
---
arch/x86/include/asm/kvm_host.h | 2 +-
arch/x86/kvm/Makefile | 4 +-
arch/x86/kvm/mmu.c |
The old way of storing protected chunks was a linked list. That made
linear overhead when searching for chunks. When reaching 2000 chunk, The
time taken two read the last chunk was about 10 times slower than the
first chunk. This patch stores the chunks as tree for faster search.
Signed-off-by: Ah
This patch introduces a hypercall that can assist against subset of kernel
rootkits, it works by place readonly protection in shadow PTE. The end
result protection is also kept in a bitmap for each kvm_memory_slot and is
used as reference when updating SPTEs. The whole goal is to protect the
guest
Signed-off-by: Ahmed Abd El Mawgood
---
arch/x86/kvm/mmu.c | 7 +++
arch/x86/kvm/mmu.h | 1 +
2 files changed, 8 insertions(+)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 098df7d135..bbfe3f2863 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -1053,6 +1053,13 @@ sta
This will help sharing data into the slot_level_handler callback. In my
case I need to a share a counter for the pages traversed to use it in some
bitmap. Being able to send arbitrary memory pointer into the
slot_level_handler callback made it easy.
Signed-off-by: Ahmed Abd El Mawgood
---
arch/x
-- Summary --
ROE is a hypercall that enables host operating system to restrict guest's access
to its own memory. This will provide a hardening mechanism that can be used to
stop rootkits from manipulating kernel static data structures and code. Once a
memory region is protected the guest kernel c
The conditions upon which kvm_free_memslot are kind of ad-hock,
it will be hard to extend memslot with allocatable data that needs to be
freed, so I replaced the current mechanism by clear flag that states if
the memory slot should be freed.
Signed-off-by: Ahmed Abd El Mawgood
---
virt/kvm/kvm_m
21 matches
Mail list logo
