Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 4 Apr 2019 10:06:43 -0600
From: Khalid Aziz <khalid.aziz@...cle.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: juergh@...il.com, tycho@...ho.ws, jsteckli@...zon.de, ak@...ux.intel.com,
        liran.alon@...cle.com, keescook@...gle.com, konrad.wilk@...cle.com,
        deepa.srinivasan@...cle.com, chris.hyser@...cle.com,
        tyhicks@...onical.com, dwmw@...zon.co.uk, andrew.cooper3@...rix.com,
        jcm@...hat.com, boris.ostrovsky@...cle.com, kanth.ghatraju@...cle.com,
        joao.m.martins@...cle.com, jmattson@...gle.com,
        pradeep.vincent@...cle.com, john.haxby@...cle.com, tglx@...utronix.de,
        kirill.shutemov@...ux.intel.com, hch@....de, steven.sistare@...cle.com,
        labbott@...hat.com, luto@...nel.org, dave.hansen@...el.com,
        akpm@...ux-foundation.org, alexander.h.duyck@...ux.intel.com,
        aneesh.kumar@...ux.ibm.com, arnd@...db.de, bigeasy@...utronix.de,
        bp@...en8.de, catalin.marinas@....com, corbet@....net,
        dan.j.williams@...el.com, gregkh@...uxfoundation.org, guro@...com,
        hannes@...xchg.org, hpa@...or.com, iamjoonsoo.kim@....com,
        james.morse@....com, jannh@...gle.com, jkosina@...e.cz,
        jmorris@...ei.org, joe@...ches.com, jrdr.linux@...il.com,
        jroedel@...e.de, keith.busch@...el.com, khlebnikov@...dex-team.ru,
        mark.rutland@....com, mgorman@...hsingularity.net,
        Michal Hocko <mhocko@...nel.org>, mike.kravetz@...cle.com,
        mingo@...hat.com, mst@...hat.com, npiggin@...il.com,
        paulmck@...ux.vnet.ibm.com, pavel.tatashin@...rosoft.com,
        rdunlap@...radead.org, richard.weiyang@...il.com, riel@...riel.com,
        rientjes@...gle.com, rostedt@...dmis.org, rppt@...ux.vnet.ibm.com,
        will.deacon@....com, willy@...radead.org, yaojun8558363@...il.com,
        ying.huang@...el.com, iommu@...ts.linux-foundation.org, x86@...nel.org,
        linux-arm-kernel@...ts.infradead.org, linux-doc@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org,
        linux-security-module@...r.kernel.org,
        Khalid Aziz <khalid@...ehiking.org>,
        kernel-hardening@...ts.openwall.com,
        "Vasileios P . Kemerlis" <vpk@...columbia.edu>
Subject: Re: [RFC PATCH v9 11/13] xpfo, mm: optimize spinlock usage in
 xpfo_kunmap

On 4/4/19 1:56 AM, Peter Zijlstra wrote:
> On Wed, Apr 03, 2019 at 11:34:12AM -0600, Khalid Aziz wrote:
>> From: Julian Stecklina <jsteckli@...zon.de>
>>
>> Only the xpfo_kunmap call that needs to actually unmap the page
>> needs to be serialized. We need to be careful to handle the case,
>> where after the atomic decrement of the mapcount, a xpfo_kmap
>> increased the mapcount again. In this case, we can safely skip
>> modifying the page table.
>>
>> Model-checked with up to 4 concurrent callers with Spin.
>>
>> Signed-off-by: Julian Stecklina <jsteckli@...zon.de>
>> Signed-off-by: Khalid Aziz <khalid.aziz@...cle.com>
>> Cc: Khalid Aziz <khalid@...ehiking.org>
>> Cc: x86@...nel.org
>> Cc: kernel-hardening@...ts.openwall.com
>> Cc: Vasileios P. Kemerlis <vpk@...columbia.edu>
>> Cc: Juerg Haefliger <juerg.haefliger@...onical.com>
>> Cc: Tycho Andersen <tycho@...ho.ws>
>> Cc: Marco Benatto <marco.antonio.780@...il.com>
>> Cc: David Woodhouse <dwmw2@...radead.org>
>> ---
>>  include/linux/xpfo.h | 24 +++++++++++++++---------
>>  1 file changed, 15 insertions(+), 9 deletions(-)
>>
>> diff --git a/include/linux/xpfo.h b/include/linux/xpfo.h
>> index 2318c7eb5fb7..37e7f52fa6ce 100644
>> --- a/include/linux/xpfo.h
>> +++ b/include/linux/xpfo.h
>> @@ -61,6 +61,7 @@ static inline void xpfo_kmap(void *kaddr, struct page *page)
>>  static inline void xpfo_kunmap(void *kaddr, struct page *page)
>>  {
>>  	unsigned long flags;
>> +	bool flush_tlb = false;
>>  
>>  	if (!static_branch_unlikely(&xpfo_inited))
>>  		return;
>> @@ -72,18 +73,23 @@ static inline void xpfo_kunmap(void *kaddr, struct page *page)
>>  	 * The page is to be allocated back to user space, so unmap it from
>>  	 * the kernel, flush the TLB and tag it as a user page.
>>  	 */
>> -	spin_lock_irqsave(&page->xpfo_lock, flags);
>> -
>>  	if (atomic_dec_return(&page->xpfo_mapcount) == 0) {
>> -#ifdef CONFIG_XPFO_DEBUG
>> -		WARN_ON(PageXpfoUnmapped(page));
>> -#endif
>> -		SetPageXpfoUnmapped(page);
>> -		set_kpte(kaddr, page, __pgprot(0));
>> -		xpfo_flush_kernel_tlb(page, 0);
>> +		spin_lock_irqsave(&page->xpfo_lock, flags);
>> +
>> +		/*
>> +		 * In the case, where we raced with kmap after the
>> +		 * atomic_dec_return, we must not nuke the mapping.
>> +		 */
>> +		if (atomic_read(&page->xpfo_mapcount) == 0) {
>> +			SetPageXpfoUnmapped(page);
>> +			set_kpte(kaddr, page, __pgprot(0));
>> +			flush_tlb = true;
>> +		}
>> +		spin_unlock_irqrestore(&page->xpfo_lock, flags);
>>  	}
>>  
>> -	spin_unlock_irqrestore(&page->xpfo_lock, flags);
>> +	if (flush_tlb)
>> +		xpfo_flush_kernel_tlb(page, 0);
>>  }
> 
> This doesn't help with the TLB invalidation issue, AFAICT this is still
> completely buggered. kunmap_atomic() can be called from IRQ context.
> 

OK. xpfo_kmap/xpfo_kunmap need redesign.

--
Khalid

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.