linux-kernel - Re: [PATCH v2 21/22] KVM: MMU: mmio page fault 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: <4E037E21.6010203@cn.fujitsu.com>
Date:	Fri, 24 Jun 2011 01:55:45 +0800
From:	Xiao Guangrong <xiaoguangrong@...fujitsu.com>
To:	Marcelo Tosatti <mtosatti@...hat.com>
CC:	Avi Kivity <avi@...hat.com>, LKML <linux-kernel@...r.kernel.org>,
	KVM <kvm@...r.kernel.org>
Subject: Re: [PATCH v2 21/22] KVM: MMU: mmio page fault support

On 06/23/2011 10:21 PM, Marcelo Tosatti wrote:

>>> An spte does not have to contain the present bit to generate a valid EPT
>>> misconfiguration (and an spte dump is still required in that case).
>>> Use !is_mmio_spte() instead.
>>>
>>
>> We can not use !is_mmio_spte() here, since the shadow page can be zapped anytime,
>> for example:
>>
>> sp.spt[i] = mmio-spte
>>
>>           VCPU 0                                    VCPU 1    
>> Access sp.spte[i], ept misconfig is occurred
>>                                                    delete sp
>>                                    (if the number of shadow page is out of the limit
>>                                     or page shrink is required, and other events...)
>>
>> Walk shadow page out of the lock and get the
>> non-present spte
>> (*the point we are discussing*)
> 
> Then is_mmio_spte(non-present spte) == false, right? Point is that it
> only sptes with precise mmio spte pattern should be considered mmio
> sptes, otherwise consider a genuine EPT misconfiguration error (which
> must be reported).
> 

No, not all no mmio spte is considered a genuine EPT misconfig, as the above
case, we can get !is_mmio_spte(), but it is not the genuine EPT misconfig
since it is caused by shadow page zapped
 
> What about using fault code instead of spte as Avi suggested instead?
> 

Do you mean waking guest page table to get mmio gva/mmio gpa for softmmu instead
of walking shadow page table?

I think it is unsafe, since guest can change the mapping anytime, we can get the
wrong mmio gva/mmio gpa to mmio emulate, consider follow case:

gva is mapped to the mmio region, we set the reserved bits in the spte:

VCPU 0                                               VCPU 1
Access gva, reserved page fault is occurred
                                             map gva to the RAM region
Walking guest page table and get the RAM gpa           TLB flush
(*the point we are discussing*)

Then we can get the wrong gpa to mmio emulate, so
- VMM can detected the invalid mmio access
- the event is missed, it neither accesses the mmio region nor the RAM region,
  it is not as the real cpu does

Anyway, mmio spte is needed to detect bugs for hard mmu

>> So, the bug we can detect is: it is the mmio access but the spte is point to the normal
>> page.
>>
>>>
>>>> +
>>>> +	/*
>>>> +	 * If the page table is zapped by other cpus, let the page
>>>> +	 * fault path to fix it.
>>>> +	 */
>>>> +	return 0;
>>>> +}
>>>
>>> I don't understand when would this happen, can you please explain?
>>>
>>
>> The case is above :-)
> 
> No need to jump to page fault handler, can let CPU fault again on non
> present spte.
> 

It is a good idea, will do, thanks!
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/