linux-kernel - Re: [PATCH v3 12/21] KVM: X86: Implement ring-based dirty memory tracking

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: <4e75a275-6687-2efc-0595-9b993ec300be@redhat.com>
Date:   Tue, 21 Jan 2020 11:24:56 +0100
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     Peter Xu <peterx@...hat.com>, "Michael S. Tsirkin" <mst@...hat.com>
Cc:     kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
        Christophe de Dinechin <dinechin@...hat.com>,
        Sean Christopherson <sean.j.christopherson@...el.com>,
        Yan Zhao <yan.y.zhao@...el.com>,
        Alex Williamson <alex.williamson@...hat.com>,
        Jason Wang <jasowang@...hat.com>,
        Kevin Kevin <kevin.tian@...el.com>,
        Vitaly Kuznetsov <vkuznets@...hat.com>,
        "Dr . David Alan Gilbert" <dgilbert@...hat.com>,
        Lei Cao <lei.cao@...atus.com>
Subject: Re: [PATCH v3 12/21] KVM: X86: Implement ring-based dirty memory
 tracking

On 20/01/20 08:29, Peter Xu wrote:
>>>
>>>    00b (invalid GFN) ->
>>>      01b (valid gfn published by kernel, which is dirty) ->
>>>        1*b (gfn dirty page collected by userspace) ->
>>>          00b (gfn reset by kernel, so goes back to invalid gfn)
>>> That is 10b and 11b are equivalent.  The kernel doesn't read that bit if
>>> userspace has collected the page.
> Yes "1*b" is good too (IMHO as long as we can define three states for
> an entry).  However do you want me to change to that?  Note that I
> still think we need to read the rest of the field (in this case,
> "slot" and "gfn") besides the two bits to do re-protect.  Should we
> trust that unconditionally if writable?

I think that userspace would only hurt itself if they do so.  As long as
the kernel has a trusted copy of the indices, it's okay.

We have plenty of bits--x86 limits GFNs to 40 bits (52 bits maximum
physical address).  However, even on other architectures GFNs are
limited to address space size - page shift (64-12).

Paolo