[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <70a9cb32-471e-9827-fae6-cd46a40c87b1@giassa.net>
Date: Tue, 14 Feb 2017 19:31:57 -0800
From: Matthew Giassa <matthew@...ssa.net>
To: Steve Rutherford <srutherford@...gle.com>
Cc: Jidong Xiao <jidong.xiao@...il.com>, kernel-hardening@...ts.openwall.com,
KVM <kvm@...r.kernel.org>, Rik van Riel <riel@...hat.com>
Subject: Re: Introduction + new project: "rootkit detection using
virtualization".
On 2017-02-14 01:25 PM, Steve Rutherford wrote:
> On Tue, Feb 14, 2017 at 10:06 AM, Matthew Giassa <matthew@...ssa.net> wrote:
>> Hi Jidong,
>>
>> You are correct on all the points noted above:My goal is to develop a
>> production-ready, non-academic implementation of such a tool. I'm in
>> it for the long haul.
> Is your goal for this to work on all architectures, or are you
> planning to focus on Intel-x86 (or AMD-x86, or ARM, or...)?
>>
>> On Fri, Feb 10, 2017 at 7:43 PM, Jidong Xiao <jidong.xiao@...il.com> wrote:
>>> Thanks Matthew. So if I understand correctly, even though many people have
>>> proposed similar solutions, none of them have actually contributed their
>>> code (of their solution) into Qemu/KVM. To make it "real" (i.e., as a part
>>> of Qemu/KVM code) is your goal, right? That sounds interesting!
>>>
>>> -Jidong
>>>
>>> On Fri, Feb 10, 2017 at 8:21 PM, Matthew Giassa <matthew@...ssa.net> wrote:
>>>>
>>>> On 2017-02-10 03:18 PM, Jidong Xiao wrote:
>>>>>
>>>>> Sorry, I have to resend this again, as the original two emails were
>>>>> blocked because of the url.
>>>>>
>>>>> "Rootkit detection using virtualization" has been widely studied for a
>>>>> decade. Is the approach you are going to use different from all of these
>>>>> existing ones:
>>>>>
>>>>> "Survey: Virtual Machine Introspection Based System Monitoring and
>>>>> Malware Detection Techniques" - by Haofu Liao at University of Rochester.
>>>>>
>>>>> -Jidong
>>>>
>>>>
>>>> On 2017-02-10 05:37 PM, Rik van Riel wrote:
>>>>>
>>>>> 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.
>>>>>
>>>>
>>>>
>>>> My initial plan was to start with what Rik proposed, and focus on
>>>> additional memory protections. With respect to long-term plans, a lot of my
>>>> work/research so far has been focused on implementing a system similar to
>>>> that presented by Payne et al (ie: Lares).
>>>>
>>>> -Matthew Giassa
>>>
>>>
>>
>>
>>
>> --
>> ============================================================
>> Matthew Giassa, MASc, BASc, EIT
>> Principal Developer; Security and Embedded Systems Specialist
>> linkedin: https://ca.linkedin.com/in/giassa
>> e-mail: matthew@...ssa.net
>> website: www.giassa.net
My initial aim is x86/x64 targets, unless there are additional resources
I can tap into for expanding to ARM. If I can get a working prototype up
and running and into "staging", then expanding to ARM architecture would
be viable.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
