linux-kernel - Re: Which architectures need to sync vmalloc mappings between processes?

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: <1171810531.3423.5.camel@mulgrave.il.steeleye.com>
Date:	Sun, 18 Feb 2007 08:55:31 -0600
From:	James Bottomley <James.Bottomley@...elEye.com>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
Cc:	linux-arch@...r.kernel.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Which architectures need to sync vmalloc mappings between
	processes?

On Sat, 2007-02-17 at 21:29 -0800, Jeremy Fitzhardinge wrote:
> I'm looking at making all architectures export a vmalloc_sync_all()
> function, so that generic code can be sure that a particular vmalloc
> mapping is present in all address spaces.   I need this to implement a
> function to reserve a chunk of vmalloc address space complete with
> constructed pagetables, but without allocating any actual data pages.
> 
> On i386 with PAE, this is not necessary because the kernel's mappings
> are shared between all processes anyway, so it would be a no-op.  
> However, non-PAE i386 has a separate kernel mapping for each process,
> and so needs to sync them - typically lazily on faults, but
> vmalloc_sync_all exists to allow mass syncing when required.
> 
> What other architectures would require syncing of vmalloc mappings, and
> what architectures would implement it as a no-op?

Er, but there are fundamental assumptions that vmalloc_sync_all() makes
that simply aren't true on other architectures.  Really, it's an
artifact of the Intel x86 processor's inability to flush by %cr3, so we
try to keep the kernel mappings alive in a process so that a sys call
and return doesn't do a full TLB flush ... and thus, because we have a
hidden piece of kernel in userspace, we get the HIGHMEM issues.

A substantial number of other architectures do have a selective TLB
flush, so a lot operate with a fully separated kernel and user space,
and thus vmalloc mappings appear only in the single kernel address space
and nowhere else.

Could you elaborate on exactly what you think you need
vmalloc_sync_all() exported for ... your explanation of a reserved
vmalloc range sounds reasonable, but should in no way depend on
vmalloc_sync_all().  It really sounds like this should be an arch
specific function so the architectures can decide the implementation
details.

James

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