From: Rik van Riel <riel@redhat.com>
To: Kees Cook <keescook@chromium.org>, Matthew Giassa <matthew@giassa.net>
Cc: "kernel-hardening@lists.openwall.com"
<kernel-hardening@lists.openwall.com>, KVM <kvm@vger.kernel.org>
Subject: Re: [kernel-hardening] Introduction + new project: "rootkit detection using virtualization".
Date: Fri, 10 Feb 2017 20:37:01 -0500 [thread overview]
Message-ID: <1486777021.2096.36.camel@redhat.com> (raw)
In-Reply-To: <CAGXu5jJXqY=KGHtrCQ3yLGVFd7K6Akk6B8VbWyZHGfRerYeV0A@mail.gmail.com>
On Fri, 2017-02-10 at 15:27 -0800, Kees Cook wrote:
> On Fri, Feb 10, 2017 at 2:00 PM, Matthew Giassa <matthew@giassa.net>
> wrote:
> > Good day,
> >
> > I am a volunteer developer taking up a project originally proposed
> > by
> > Rik van Riel, "rootkit detection using virtualization", and am
> > planning to contribute regularly to this project over the coming
> > months. I was advised to contact these mailing lists to introduce
> > myself, and I also wanted to inquire about any existing projects
> > that
> > coincide with this work. My initial work will involved diving into
> > KVM
> > + qemu source and deciding how best to approach the problem. While
> > I
> > have the attention of list members, are there any specific
> > individuals/groups I should contact directly with respect to this
> > type
> > of project?
> >
> > Thank you.
>
> Hi! Welcome to the list(s)!
>
> I think this is an interesting area of research, though it may be a
> tricky cat/mouse game. Some of this kind of
> hypervisor-protects-the-kernel work has been done on some Android
> phones in small areas (see the cred protection near the end):
>
> http://keenlab.tencent.com/en/2016/06/01/Emerging-Defense-in-Android-
> Kernel/
One of the things that Matthew can do is build on
the read-only memory protections in the kernel, and
have the hypervisor enforce that the memory the kernel
marks as read-only is never written from inside the
virtual machine, until the next reboot.
That seems like it might be a useful place to start,
since it would immediately make the other read-only
protections that people are working on much harder to
get around, at least inside virtual machines.
next prev parent reply other threads:[~2017-02-11 1:37 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-10 22:00 [kernel-hardening] Introduction + new project: "rootkit detection using virtualization" Matthew Giassa
2017-02-10 22:00 ` Matthew Giassa
2017-02-10 23:14 ` [kernel-hardening] " Jidong Xiao
2017-02-10 23:14 ` Jidong Xiao
2017-02-10 23:18 ` [kernel-hardening] " Jidong Xiao
2017-02-10 23:18 ` Jidong Xiao
2017-02-11 3:21 ` [kernel-hardening] " Matthew Giassa
2017-02-11 3:21 ` Matthew Giassa
2017-02-11 3:43 ` [kernel-hardening] " Jidong Xiao
2017-02-11 3:43 ` Jidong Xiao
2017-02-14 18:06 ` [kernel-hardening] " Matthew Giassa
2017-02-14 18:06 ` Matthew Giassa
2017-02-14 21:25 ` [kernel-hardening] " Steve Rutherford
2017-02-14 21:25 ` Steve Rutherford
2017-02-15 3:31 ` [kernel-hardening] " Matthew Giassa
2017-02-15 3:31 ` Matthew Giassa
2017-02-16 6:31 ` [kernel-hardening] " Grandhi, Sainath
2017-02-16 6:31 ` Grandhi, Sainath
2017-02-17 1:16 ` [kernel-hardening] " Matthew Giassa
2017-02-17 1:16 ` Matthew Giassa
2017-02-10 23:27 ` [kernel-hardening] " Kees Cook
2017-02-10 23:31 ` Kees Cook
2017-02-11 1:37 ` Rik van Riel [this message]
2017-02-13 8:41 ` Matthew Garrett
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1486777021.2096.36.camel@redhat.com \
--to=riel@redhat.com \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=kvm@vger.kernel.org \
--cc=matthew@giassa.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.