On Aug 3, 2016 10:54 PM, "Kees Cook" wrote: > > On Wed, Aug 3, 2016 at 10:45 PM, Andy Lutomirski wrote: > > On Wed, Aug 3, 2016 at 10:32 PM, Kees Cook wrote: > >> On Wed, Aug 3, 2016 at 3:53 PM, Catalin Marinas < catalin.marinas@arm.com> wrote: > >>> On 1 Aug 2016, at 00:05, Kees Cook wrote: > >>>> On Sun, Jul 31, 2016 at 2:55 AM, Paul Burton wrote: > >>>>> It would be very interesting to discuss what's needed from arch code for > >>>>> various hardening features, both those currently in mainline & those in > >>>>> development. > >>> > >>> I'm interested in such topic as well, primarily from an arm/arm64 perspective. > >>> > >>>> - Handling userspace/kernelspace memory segregation. (This is the SMAP > >>>> of x86, PAN of ARM, and just native on s390.) For architectures (or > >>>> chipsets within an architecture) that don't support unprivileged > >>>> memory access restrictions in hardware, we must find a way to emulate > >>>> it. (e.g. 32-bit ARM uses Domains, and 64-bit x86 could use PCIDs, > >>>> etc.) Keeping these regions separate is extremely important in > >>>> stopping exploitation. > >>> > >>> For arm64 ARMv8.0 (without hardware PAN), I'm going to post a patch > >>> in a week or so which emulates PAN by switching the user page table (TTBR0) > >>> to the zero page. I guess a similar approach could work for other architectures, > >>> maybe using swapper_pg_dir as the PAN page table. > >> > >> At least on x86 I've heard grumblings that it can be prohibitively > >> expensive due to TLB-flushing, but I'd still like to see an > >> implementation doing it first. :) > > > > No TLB flush needed if we use PCID. Linus will attack you with a > > pitchfork either way, though :) > > Hmm, my asbestos suit won't help me there. I will need to invest in titanium. :) > > The TLB flushing way I can understand being pitchfork-worthy, though > I'm curious why a PCID implementation would be upsetting? I think the problem is the page table switch, not the PCID. > > > It shouldn't be *that* hard to build this thing on top of my PCID > > patchset. I need to dust that off, which I'll do right after vmap > > stacks land and I finish fsgsbase. Sigh, so many things. > > What does your PCID series do? It uses PCID for what it looks like it was designed for: faster context switches. AFAICT it was actually designed for user/kernel switching on Mac OS X, which, if true, would explain some design oddities.