linux-kernel - [PATCH] Workaround change_page_attr() and global_flush_tlb() df

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: <20070619211049.GA9234@Krystal>
Date:	Tue, 19 Jun 2007 17:10:49 -0400
From:	Mathieu Desnoyers <compudj@...stal.dyndns.org>
To:	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
	ak@...e.de, mingo@...hat.com
Cc:	mbligh@...gle.com
Subject: [PATCH] Workaround change_page_attr() and global_flush_tlb() df_list inconsistency on i386

* Mathieu Desnoyers (compudj@...stal.dyndns.org) wrote:
> Looking more closely into the code to find the cause of the
> change_page_addr()/global_flush_tlb() inconsistency, I see where the
> problem could be:
> 
> In arch/i386/mm/pageattr.c:
> __change_page_attr adds the page to the df_list for deferred removal
> when it is replaced by a large page (going back to the normal flags).
> This list is walked by global_flush_tlb(); it calls flush_map() and
> __free_page for each of these pages.
> 
> flush_map() is the only call that ends up doing a clflush/wbinvd and
> __flush_tlb_all() on every cpu. However, this is only done when there
> are pages recombined in a large page. It never happens when we set the
> page flags to something unusual in __change_page_attr().
> 
> The x86_64 implementation seems to work around this issue by doing a
> flush_map() independently of the deferred_pages list. It will therefore
> call __flush_tlb_all(), which should flush the TLB, but even there, I
> wonder if it should call clflush on the pages that had their flags
> modified by __change_page_attr() ?
> 
> Some input about the best way to fix this (adding the modified pages to
> the deferred list in __change_page_attr() or flushing all the TLBs, and
> all caches, independently of the deferred pages list in
> global_flush_tlb()) would be appreciated. If we add the pages that
> simply had their flags modified to the df_list, would it be ok to issue
> a __free_page on them ?
> 


Workaround change_page_attr() and global_flush_tlb() df_list inconsistency on i386

global_flush_tlb() does not flush the tlb of pages that had their flags changed
by change_page_attr(). It only deals with the pages that are set back to their
normal flags.

Waiting for comments about a cleaner fix, this one does the job.

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
---
 arch/i386/mm/pageattr.c |    2 ++
 1 file changed, 2 insertions(+)

Index: linux-2.6-lttng/arch/i386/mm/pageattr.c
===================================================================
--- linux-2.6-lttng.orig/arch/i386/mm/pageattr.c	2007-06-19 15:34:14.000000000 -0400
+++ linux-2.6-lttng/arch/i386/mm/pageattr.c	2007-06-19 16:49:52.000000000 -0400
@@ -232,6 +232,8 @@
 			flush_map(page_address(pg));
 		__free_page(pg);
 	}
+	/* Workaround change page attr list missing entries */
+	flush_map(NULL);
 }
 
 #ifdef CONFIG_DEBUG_PAGEALLOC
-- 
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
-
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/