From: Suen Chun Hui <chunhui.suen@tum.de>
To: kvm@vger.kernel.org
Subject: Re: KVM hook for code integrity checking
Date: Thu, 06 May 2010 06:51:53 +0200 [thread overview]
Message-ID: <4BE24AE9.6040102@tum.de> (raw)
In-Reply-To: <4BE134C1.1020009@redhat.com>
Hi,
Thanks for the reply.
On 05/05/2010 11:05 AM, Avi Kivity wrote:
> On 04/30/2010 05:53 PM, Suen Chun Hui wrote:
>> Dear KVM developers,
>>
>> I'm currently working on an open source security patch to use KVM to
>> implement code verification on a guest VM in runtime. Thus, it would be
>> very helpful if someone can point to me the right function or place to
>> look at for adding 2 hooks into the KVM paging code to:
>>
>> 1. Detect a new guest page (which I assume will imply a new pte and
>> imply a new spte).
>> Currently, I'm considering putting a hook in the function
>> mmu_set_spte(), but may there is a better place.
>> This hook will be used as the main entry point into the code
>> verification function
>>
>
> This is in general not possible. Hosts with npt or ept will not see
> new guest ptes.
>
Yes, I was only considering the case of using shadow paging. Would this
be possible then, since the walker would have to parse gpte anyway?
> It could be done with physical pages, but you'll have no way of
> knowing if the pages are used in userspace, the kernel, or both.
>
>> 2. Detect a write fault to a read-only spte (eg. for the case of
>> updating the dirty bit back to the guest pte)
>> Unfortunately, I'm unable to find an appropriate place where this
>> actually takes place after reading the code many times.
>> This hook will be used to prevent a secondary "peek" page from modifying
>> an existing verified code page.
>>
>
> set_spte() or mmu_set_spte() may work.
>
next prev parent reply other threads:[~2010-05-06 4:52 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-30 14:53 KVM hook for code integrity checking Suen Chun Hui
2010-05-05 9:05 ` Avi Kivity
2010-05-06 4:51 ` Suen Chun Hui [this message]
2010-05-06 9:04 ` Avi Kivity
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=4BE24AE9.6040102@tum.de \
--to=chunhui.suen@tum.de \
--cc=kvm@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).