linux-kernel - Re: Crash on kvm_iommu_map

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]

Date:	Mon, 01 Nov 2010 16:29:27 +0100
From:	Jan Kiszka <jan.kiszka@....de>
To:	Joerg Roedel <joro@...tes.org>
CC:	"Roedel, Joerg" <Joerg.Roedel@....com>, kvm <kvm@...r.kernel.org>,
	Sheng Yang <sheng@...ux.intel.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Crash on kvm_iommu_map_pages

Am 01.11.2010 15:35, Joerg Roedel wrote:
> On Mon, Nov 01, 2010 at 03:22:15PM +0100, Jan Kiszka wrote:
>> Am 01.11.2010 14:53, Roedel, Joerg wrote:
>>> On Mon, Nov 01, 2010 at 09:25:00AM -0400, Jan Kiszka wrote:
>>>> Am 01.11.2010 14:21, Roedel, Joerg wrote:
>>>>> The registers rax and rbx contain non-canonical addresses (if
>>>>> interpreted as pointers). The instruction where this happens is a mov so
>>>>> I guess that the #GP is because of an non-canonical address.
>>>>> Can you find out the code-line where this happens and the exact
>>>>> assembler instruction? (haven't managed to decode the registers used).
>>>>
>>>> In pfn_to_dma_pte, line 710:
>>>>
>>>>                 if (!dma_pte_present(pte)) {
>>>> ffffffff8121de8c:       f6 03 03                testb  $0x3,(%rbx)
>>>> ffffffff8121de8f:       0f 85 d8 00 00 00       jne    ffffffff8121df6d <pfn_to_dma_pte+0x154>
>>>>
>>>> The first instruction raises the fault.
>>>
>>> Ok, so it seems that my understanding of the Code: field in the
>>> crash-message was wrong :)
>>> Anyway, the testb uses rbx as an address which has a non-canonical
>>> value. This means the the address of 'pte' is invalid. Since rax also
>>> contains a wrong address the 'parent' variable probably already contains
>>> the wrong address. Does the attached patch help?
>>>
>>> diff --git a/include/linux/dma_remapping.h b/include/linux/dma_remapping.h
>>> index 5619f85..ca46f24 100644
>>> --- a/include/linux/dma_remapping.h
>>> +++ b/include/linux/dma_remapping.h
>>> @@ -6,7 +6,7 @@
>>>   */
>>>  #define VTD_PAGE_SHIFT		(12)
>>>  #define VTD_PAGE_SIZE		(1UL << VTD_PAGE_SHIFT)
>>> -#define VTD_PAGE_MASK		(((u64)-1) << VTD_PAGE_SHIFT)
>>> +#define VTD_PAGE_MASK		((((u64)-1) << VTD_PAGE_SHIFT) & ((1ULL << 52) - 1))
>>>  #define VTD_PAGE_ALIGN(addr)	(((addr) + VTD_PAGE_SIZE - 1) & VTD_PAGE_MASK)
>>>  
>>>  #define DMA_PTE_READ (1)
>>>
>>
>> Crashes during early boot while initializing dmar. If you need the
>> trace, I could set up some debug console.
> 
> Hmm, no. This was only a guess. The VTD_PAGE_MASK does not mask out the
> bits 52-63 of the pte. According to the VT-d spec it is allowed to set
> these bits, some are marked as AVL and some have special meanings. If a
> pte has one of these bits set the phys_addr calculated will be wrong and
> the virt_addr calculated from it too (probably non-canonical, leading to
> the GPF). 
> 
> Probably masking out these bits in dma_pte_addr helps. 
> 

Nope. But I just noticed a fatal thinko in my fix to
intel_iommu_attach_device - probably that was the key. Need to boot the
test kernel...

Jan


Download attachment "signature.asc" of type "application/pgp-signature" (260 bytes)