search for: ahmedsoliman0x666

Hi, This is my first set of patches that works as I would expect, and the third revision I sent to mailing lists. Following up with my previous discussions about kernel rootkit mitigation via placing R/O protection on critical data structure, static data, privileged registers with static content. These patches present the first part where it is only possible to place these protections on memory

Hi, This is my first set of patches that works as I would expect, and the third revision I sent to mailing lists. Following up with my previous discussions about kernel rootkit mitigation via placing R/O protection on critical data structure, static data, privileged registers with static content. These patches present the first part where it is only possible to place these protections on memory

Following up with my previous threads on KVM assisted Anti rootkit protections. The current version doesn't address the attacks involving pages remapping. It is still design in progress, nevertheless, it will be in my later patch sets. Signed-off-by: Ahmed Abd El Mawgood <ahmedsoliman0x666 at gmail.com> --- Documentation/virtual/kvm/hypercalls.txt | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/Documentation/virtual/kvm/hypercalls.txt b/Documentation/virtual/kvm/hypercalls.txt index a890529c63ed..a9db68adb7c9 100644 --- a/Documentation/virtual/kvm/hypercalls.t...

Here is change log from V3 To V4: - Fixing spelling/grammar mistakes suggested by Randy Dunlap - Changing the hypercall interface to be able to process multiple pages per one hypercall also suggested by Randy Dunlap. It turns out that this will save lots of vmexist/memory slot flushes when protecting many pages. [PATCH RFC V4 1/3] KVM: X86: Memory ROE documentation [PATCH RFC V4 2/3] KVM:

On 20 July 2018 at 03:28, Jann Horn <jannh at google.com> wrote: > On Fri, Jul 20, 2018 at 2:26 AM Ahmed Soliman > <ahmedsoliman0x666 at gmail.com> wrote: >> >> On 20 July 2018 at 00:59, Jann Horn <jannh at google.com> wrote: >> > On Thu, Jul 19, 2018 at 11:40 PM Ahmed Abd El Mawgood >> >> > Why are you implementing this in the kernel, instead of doing it in >> > host userspac...

...o revert effect of Memory ROE hypercall. This patch doesn't implement integrity check on guest TLB so obvious attack on the current implementation will involve guest virtual address -> guest physical address remapping, but there are plans to fix that. Signed-off-by: Ahmed Abd El Mawgood <ahmedsoliman0x666 at gmail.com> --- arch/x86/include/asm/kvm_host.h | 11 +++++- arch/x86/kvm/Kconfig | 7 ++++ arch/x86/kvm/mmu.c | 72 ++++++++++++++++++++++++++++++------ arch/x86/kvm/x86.c | 82 +++++++++++++++++++++++++++++++++++++++-- include/linux/kvm_host.h |...

...o revert effect of Memory ROE hypercall. This patch doesn't implement integrity check on guest TLB so obvious attack on the current implementation will involve guest virtual address -> guest physical address remapping, but there are plans to fix that. Signed-off-by: Ahmed Abd El Mawgood <ahmedsoliman0x666 at gmail.com> --- arch/x86/include/asm/kvm_host.h | 11 ++++- arch/x86/kvm/Kconfig | 7 +++ arch/x86/kvm/mmu.c | 72 +++++++++++++++++++++++----- arch/x86/kvm/x86.c | 104 ++++++++++++++++++++++++++++++++++++++-- include/linux/kvm_host.h | 3 ++...

On 19 June 2018 at 19:37, David Vrabel <david.vrabel at nutanix.com> wrote: > It's not clear how this increases security. What threats is this > protecting again? It won't completely protect prevent rootkits, because still rootkits can edit dynamic kernel data structures, but it will limit what rootkits damage to only dynamic data. This way system calls can't be changed, or

On 20 July 2018 at 00:59, Jann Horn <jannh at google.com> wrote: > On Thu, Jul 19, 2018 at 11:40 PM Ahmed Abd El Mawgood > Why are you implementing this in the kernel, instead of doing it in > host userspace? I thought about implementing it completely in QEMU but It won't be possible for few reasons: - After talking to QEMU folks I came up to conclusion that it when it comes

Shortly after I sent the first email, we found that there is another way to achieve this kind of communication, via KVM Hypercalls, I think they are underutilised in kvm, but they exist. We also found that they are architecture dependent, but the advantage is that one doesn't need to create QEMU<-> kvm interface So from our point of view it is either have things easily compatible with

Following up on these threads: - https://marc.info/?l=kvm&m=151929803301378&w=2 - http://www.openwall.com/lists/kernel-hardening/2018/02/22/18 I lost the original emails so I couldn't reply to them, and also sorry for being late, it was the end of semester exams. I was adviced on #qemu and #kernelnewbies IRCs to ask here as it will help having better insights. To wrap things up, the

Following up on these threads: - https://marc.info/?l=kvm&m=151929803301378&w=2 - http://www.openwall.com/lists/kernel-hardening/2018/02/22/18 I lost the original emails so I couldn't reply to them, and also sorry for being late, it was the end of semester exams. I was adviced on #qemu and #kernelnewbies IRCs to ask here as it will help having better insights. To wrap things up, the