linux-kernel - Re: [Xen-devel] [PATCH 02/13] xen: anchor linear p2m list in shared info structure

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:	Wed, 18 Feb 2015 10:51:42 +0000
From:	David Vrabel <david.vrabel@...rix.com>
To:	Juergen Gross <jgross@...e.com>,
	David Vrabel <david.vrabel@...rix.com>,
	<linux-kernel@...r.kernel.org>, <xen-devel@...ts.xensource.com>,
	<konrad.wilk@...cle.com>, <boris.ostrovsky@...cle.com>
Subject: Re: [Xen-devel] [PATCH 02/13] xen: anchor linear p2m list in shared
 info structure

On 18/02/15 10:42, Juergen Gross wrote:
> On 02/18/2015 11:32 AM, David Vrabel wrote:
>> On 18/02/15 06:51, Juergen Gross wrote:
>>> The linear p2m list should be anchored in the shared info structure
>>
>> I'm not really sure what you mean by "anchored".
> 
> Bad wording? What about:
> 
> The virtual address of the linear p2m list should be stored in the
> shared info structure.

This is better.

>>> read by the Xen tools to be able to support 64 bit pv-domains larger
>>> than 512 MB. Additionally the linear p2m list interface includes a
>>> generation count which is changed prior to and after each mapping
>>> change of the p2m list. Reading the generation count the Xen tools can
>>> detect changes of the mappings and re-read the p2m list eventually.
>> [...]
>>> --- a/arch/x86/xen/p2m.c
>>> +++ b/arch/x86/xen/p2m.c
>>> @@ -256,6 +256,10 @@ void xen_setup_mfn_list_list(void)
>>>       HYPERVISOR_shared_info->arch.pfn_to_mfn_frame_list_list =
>>>           virt_to_mfn(p2m_top_mfn);
>>>       HYPERVISOR_shared_info->arch.max_pfn = xen_max_p2m_pfn;
>>> +    HYPERVISOR_shared_info->arch.p2m_generation = 0;
>>> +    HYPERVISOR_shared_info->arch.p2m_vaddr = (unsigned
>>> long)xen_p2m_addr;
>>> +    HYPERVISOR_shared_info->arch.p2m_cr3 =
>>> +        xen_pfn_to_cr3(virt_to_mfn(swapper_pg_dir));
>>>   }
>>>
>>>   /* Set up p2m_top to point to the domain-builder provided p2m pages */
>>> @@ -469,8 +473,10 @@ static pte_t *alloc_p2m_pmd(unsigned long addr,
>>> pte_t *pte_pg)
>>>
>>>           ptechk = lookup_address(vaddr, &level);
>>>           if (ptechk == pte_pg) {
>>> +            HYPERVISOR_shared_info->arch.p2m_generation++;
>>>               set_pmd(pmdp,
>>>                   __pmd(__pa(pte_newpg[i]) | _KERNPG_TABLE));
>>> +            HYPERVISOR_shared_info->arch.p2m_generation++;
>>
>> Do these increments of p2m_generation need to be atomic?
> 
> Hmm, they are done under lock.

Ok, atomic isn't necessary.

> I don't think the compiler is allowed to
> reorder the writes to p2m_generation across set_pmd().

Ok. but I think you also need to prevent the processor reordering the
writes so I think some write barriers are needed here.  (The toolstack
would then need the corresponding read barriers when checking the
p2m_generation.)

David
--
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/