linux-kernel - Re: [PATCH v5 04/13] KVM: Introduce a new guest mapping API

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: <6e3f4c34-72c0-2abe-91b9-6c06ea86785d@redhat.com>
Date:   Wed, 30 Jan 2019 18:08:56 +0100
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
        KarimAllah Ahmed <karahmed@...zon.de>
Cc:     linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
        rkrcmar@...hat.com
Subject: Re: [PATCH v5 04/13] KVM: Introduce a new guest mapping API

On 23/01/19 18:50, Konrad Rzeszutek Wilk wrote:
>> +	if (dirty)
>> +		kvm_release_pfn_dirty(map->pfn);
>> +	else
>> +		kvm_release_pfn_clean(map->pfn);
>> +	map->hva = NULL;
> I keep on having this gnawing feeling that we MUST set map->page to
> NULL.
> 
> That is I can see how it is not needed if you are using 'map' and
> 'unmap' together - for that we are good. But what I am worried is that
> some one unmaps it .. and instead of checking map->hva they end up
> checking map->page and think the page is mapped.

I think that would break anyway the memremap case.

So I think we should indeed reset map->page, but we should set it to a
poison value:

#define KVM_UNMAPPED_PAGE    ((void *) 0x500 + POISON_POINTER_DELTA)

mem->page = KVM_UNMAPPED_PAGE;

This should make it clear to everyone that checking map->page is _not_
the right thing to do in any case.

Paolo

> Would you be OK adding that extra statement just as a fail-safe
> mechanism in case someones misues the APIs?