linux-kernel - Re: [PATCH v3 04/34] KVM: x86: hyper-v: Handle HVCALL_FLUSH_VIRTUAL_ADDRESS

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: <87y1yyucis.fsf@redhat.com>
Date:   Wed, 18 May 2022 16:43:39 +0200
From:   Vitaly Kuznetsov <vkuznets@...hat.com>
To:     Sean Christopherson <seanjc@...gle.com>
Cc:     Maxim Levitsky <mlevitsk@...hat.com>,
        Wanpeng Li <wanpengli@...cent.com>,
        Jim Mattson <jmattson@...gle.com>,
        Michael Kelley <mikelley@...rosoft.com>,
        Siddharth Chandrasekaran <sidcha@...zon.de>,
        linux-hyperv@...r.kernel.org, linux-kernel@...r.kernel.org,
        kvm@...r.kernel.org, Paolo Bonzini <pbonzini@...hat.com>
Subject: Re: [PATCH v3 04/34] KVM: x86: hyper-v: Handle
 HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST{,EX} calls gently

Sean Christopherson <seanjc@...gle.com> writes:

> On Wed, May 18, 2022, Vitaly Kuznetsov wrote:
>> Maxim Levitsky <mlevitsk@...hat.com> writes:
>> > Or if using kfifo, then it can contain plain u64 items, which is even more natural.
>> >
>> 
>> In the next version I switch to fifo and get rid of 'flush_all' entries
>> but instead of a boolean I use a 'magic' value of '-1' in GVA. This way
>> we don't need to synchronize with the reader and add any special
>> handling for the flag.
>
> Isn't -1 theoretically possible?  Or is wrapping not allowed?  E.g. requesting a
> flush for address=0xfffffffffffff000, count = 0xfff will yield -1 and doesn't
> create any illegal addresses in the process.
>

Such an error would just lead to KVM flushing the whole guest address
space instead of flushing 4096 pages starting with 0xfffffffffffff000
but over-flushing is always architecturally correct, isn't it?

Personally, I'm not opposed to dropping the magic and enhancing flush
entries with 'flags' again but I'd like to avoid keeping this info
somewhere aside. Also, after we switch to kfifo, we can't play with
ring indexes to somehow indicate this special case. We probably can use
'fifo is full' as such indication but this is very, very un-obvious.

-- 
Vitaly