linux-kernel - Re: [PATCH RFC 00/10] Intel EPT-Based Sub-page Write Protection Support.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ceeb1137-8eeb-a848-16ff-4c9bd60609ee@redhat.com>
Date:   Thu, 19 Oct 2017 13:57:12 +0200
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     Jim Mattson <jmattson@...gle.com>, kvm list <kvm@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Radim Krčmář <rkrcmar@...hat.com>,
        Alex Williamson <alex.williamson@...hat.com>
Subject: Re: [PATCH RFC 00/10] Intel EPT-Based Sub-page Write Protection
 Support.

On 18/10/2017 16:07, Yi Zhang wrote:
> On 2017-10-18 at 11:35:12 +0200, Paolo Bonzini wrote:
>>>
>>> Currently,  We only block the write access, As far as I know an example,
>>> we now using it in a security daemon:
>>
>> Understood.  However, I think QEMU is the wrong place to set this up.
>>
>> If the kernel wants to protect _itself_, it should use a hypercall.  If
>> an introspector appliance wants to protect the guest kernel, it should
>> use the socket that connects it to the hypervisor.
>>
>> Paolo
>>
> 
> Thanks Paolo,
> 
> Yes, that correctable, I will think about to switch the interface to a
> hypercall,  How about we keep these 2 interface together(hyper call +
> ioctl)? think about that if VMM manager have some way could intercept
> the guest kernel memory accessing, the page protection would like a
> hardware watch point, is it an easy way to let VMM manager debug the
> guest kernel?

I would leave out the ioctl without a use case.  It's always tricky to
add APIs without a user, as the risk of bit rot is high.  But if
somebody comes up with a matching useful patch for QEMU or kvmtool, it's
fine.

> Except the interface change, could you please help to review the other
> patch series? just skip the ioctl patch( patch 7). 

Yes, of course.

Paolo