linux-kernel - Re: [PATCH RFC] vm_unmap_aliases: allow callers to inhibit TLB flush

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, 23 Feb 2009 15:14:00 +1100
From:	Nick Piggin <nickpiggin@...oo.com.au>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linux Memory Management List <linux-mm@...ck.org>,
	"the arch/x86 maintainers" <x86@...nel.org>,
	Arjan van de Ven <arjan@...ux.intel.com>
Subject: Re: [PATCH RFC] vm_unmap_aliases: allow callers to inhibit TLB flush

On Friday 20 February 2009 06:11:32 Jeremy Fitzhardinge wrote:
> Nick Piggin wrote:
> > Then what is the point of the vm_unmap_aliases? If you are doing it
> > for security it won't work because other CPUs might still be able
> > to write through dangling TLBs. If you are not doing it for
> > security then it does not need to be done at all.
>
> Xen will make sure any danging tlb entries are flushed before handing
> the page out to anyone else.
>
> > Unless it is something strange that Xen does with the page table
> > structure and you just need to get rid of those?
>
> Yeah.  A pte pointing at a page holds a reference on it, saying that it
> belongs to the domain.  You can't return it to Xen until the refcount is 0.

OK. Then I will remember to find some time to get the interrupt
safe patches working. I wonder why you can't just return it to
Xen when (or have Xen hold it somewhere until) the refcount
reaches 0?

Anyway...

> > Or... what if we just allow a compile and/or boot time flag to direct
> > that it does not want lazy vmap unmapping and it will just revert to
> > synchronous unmapping? If Xen needs lots of flushing anyway it might
> > not be a win anyway.
>
> That may be worth considering.

... in the meantime, shall we just do this for Xen? It is probably
safer and may end up with no worse performance on Xen anyway. If
we get more vmap users and it becomes important, you could look at
more sophisticated ways of doing this. Eg. a page could be flagged
if it potentially has lazy vmaps.

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