linux-kernel - Re: [RFC PATCH 10/13] mm: Introduce first class virtual address spaces

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] [day] [month] [year] [list]

Date:   Mon, 13 Mar 2017 19:34:27 -0700
From:   Till Smejkal <till.smejkal@...glemail.com>
To:     Vineet Gupta <Vineet.Gupta1@...opsys.com>
Cc:     Till Smejkal <till.smejkal@...glemail.com>,
        Richard Henderson <rth@...ddle.net>,
        Ivan Kokshaysky <ink@...assic.park.msu.ru>,
        Matt Turner <mattst88@...il.com>,
        Russell King <linux@...linux.org.uk>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will.deacon@....com>,
        Steven Miao <realmz6@...il.com>,
        Richard Kuo <rkuo@...eaurora.org>,
        Tony Luck <tony.luck@...el.com>,
        Fenghua Yu <fenghua.yu@...el.com>,
        James Hogan <james.hogan@...tec.com>,
        Ralf Baechle <ralf@...ux-mips.org>,
        "James E.J. Bottomley" <jejb@...isc-linux.org>,
        Helge Deller <deller@....de>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        Paul Mackerras <paulus@...ba.org>,
        Michael Ellerman <mpe@...erman.id.au>,
        Martin Schwidefsky <schwidefsky@...ibm.com>,
        Heiko Carstens <heiko.carstens@...ibm.com>,
        Yoshinori Sato <ysato@...rs.sourceforge.jp>,
        Rich Felker <dalias@...c.org>,
        "David S. Miller" <davem@...opsys.COM>,
        linux-kernel@...r.kernel.org, linux-alpha@...r.kernel.org,
        linux-snps-arc@...ts.infradead.org,
        linux-arm-kernel@...ts.infradead.org,
        adi-buildroot-devel@...ts.sourceforge.net,
        linux-hexagon@...r.kernel.org, linux-ia64@...r.kernel.org,
        linux-metag@...r.kernel.org, linux-mips@...ux-mips.org,
        linux-parisc@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org,
        linux-s390@...r.kernel.org, linux-sh@...r.kernel.org,
        sparclinux@...r.kernel.org, linux-xtensa@...ux-xtensa.org,
        linux-media@...r.kernel.org, linux-mtd@...ts.infradead.org,
        linux-usb@...r.kernel.org, linux-fsdevel@...r.kernel.org,
        linux-aio@...ck.org, linux-mm@...ck.org, linux-api@...r.kernel.org,
        linux-arch@...r.kernel.org, alsa-devel@...a-project.org,
        Ingo Molnar <mingo@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Andy Lutomirski <luto@...capital.net>
Subject: Re: [RFC PATCH 10/13] mm: Introduce first class virtual address
 spaces

Hi Vineet,

On Mon, 13 Mar 2017, Vineet Gupta wrote:
> I've not looked at the patches closely (or read the references paper fully yet),
> but at first glance it seems on ARC architecture, we can can potentially
> use/leverage this mechanism to implement the shared TLB entries. Before anyone
> shouts these are not same as the IA64/x86 protection keys which allow TLB entries
> with different protection bits across processes etc. These TLB entries are
> actually *shared* by processes.
> 
> Conceptually there's shared address spaces, independent of processes. e.g. ldso
> code is shared address space #1, libc (code) #2 .... System can support a limited
> number of shared addr spaces (say 64, enough for typical embedded sys).
> 
> While Normal TLB entries are tagged with ASID (Addr space ID) to keep them unique
> across processes, Shared TLB entries are tagged with Shared address space ID.
> 
> A process MMU context consists of ASID (a single number) and a SASID bitmap (to
> allow "subscription" to multiple Shared spaces. The subscriptions are set up bu
> userspace ld.so which knows about the libs process wants to map.
> 
> The restriction ofcourse is that the spaces are mapped at *same* vaddr is all
> participating processes. I know this goes against whole security, address space
> randomization - but it gives much better real time performance. Why does each
> process need to take a MMU exception for libc code...
> 
> So long story short - it seems there can be multiple uses of this infrastructure !

During the development of this code, we also looked at shared TLB entries, but
the other way around. We wanted to use them to prevent flushing of TLB entries of
shared memory regions when switching between multiple ASes. Unfortunately, we never
finished this part of the code.

However, we also investigated into a different use-case for first class virtual
address spaces that is related to what you propose if I didn't understand something
wrong. The idea is to move shared libraries into their own first class virtual
address space and only load some small trampoline code in the application AS. This
trampoline code performs the VAS switch in the libraries AS and execute the requested
function there. If we combine this architecture with tagged TLB entries to prevent
TLB flushes during the switch operation, it can also reach an acceptable performance.
A side effect of moving the shared library into its own AS is that it can not be used
by ROP-attacks because it is not accessible in the application's AS.

Till