From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-f43.google.com (mail-oi0-f43.google.com [209.85.218.43]) by kanga.kvack.org (Postfix) with ESMTP id EFDAC6B0275 for ; Tue, 29 Dec 2015 08:13:09 -0500 (EST) Received: by mail-oi0-f43.google.com with SMTP id o62so182411705oif.3 for ; Tue, 29 Dec 2015 05:13:09 -0800 (PST) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com. [2607:f8b0:4003:c01::232]) by mx.google.com with ESMTPS id fo4si25948254obb.104.2015.12.29.05.13.09 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 Dec 2015 05:13:09 -0800 (PST) Received: by mail-ob0-x232.google.com with SMTP id 18so252014490obc.2 for ; Tue, 29 Dec 2015 05:13:09 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: From: Andy Lutomirski Date: Tue, 29 Dec 2015 05:12:49 -0800 Message-ID: Subject: Re: [PATCH v2 0/6] mm, x86/vdso: Special IO mapping improvements Content-Type: text/plain; charset=UTF-8 Sender: owner-linux-mm@kvack.org List-ID: To: Andy Lutomirski , Oleg Nesterov , Kees Cook Cc: X86 ML , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , Andrew Morton , Borislav Petkov On Wed, Dec 23, 2015 at 3:56 PM, Andy Lutomirski wrote: > Hi Oleg and Kees- > > I meant to cc you on this in the first place, but I failed. If you > have a few minutes, want to take a peek at these and see if you can > poke any holes in them? I'm reasonably confident that they're a > considerable improvement over the old state of affairs, but they might > still not be perfect. > > Let me know if you want me to email out a fresh copy. This series > applies to tip:x86/asm. Hi -tip people: please don't apply this series. It has a race. I'll send v3. --Andy > > --Andy > > On Mon, Dec 14, 2015 at 10:31 AM, Andy Lutomirski wrote: >> This applies on top of the earlier vdso pvclock series I sent out. >> Once that lands in -tip, this will apply to -tip. >> >> This series cleans up the hack that is our vvar mapping. We currently >> initialize the vvar mapping as a special mapping vma backed by nothing >> whatsoever and then we abuse remap_pfn_range to populate it. >> >> This cheats the mm core, probably breaks under various evil madvise >> workloads, and prevents handling faults in more interesting ways. >> >> To clean it up, this series: >> >> - Adds a special mapping .fault operation >> - Adds a vm_insert_pfn_prot helper >> - Uses the new .fault infrastructure in x86's vdso and vvar mappings >> - Hardens the HPET mapping, mitigating an HW attack surface that bothers me >> >> akpm, can you ack patck 1? >> >> Changes from v1: >> - Lots of changelog clarification requested by akpm >> - Minor tweaks to style and comments in the first two patches >> >> Andy Lutomirski (6): >> mm: Add a vm_special_mapping .fault method >> mm: Add vm_insert_pfn_prot >> x86/vdso: Track each mm's loaded vdso image as well as its base >> x86,vdso: Use .fault for the vdso text mapping >> x86,vdso: Use .fault instead of remap_pfn_range for the vvar mapping >> x86/vdso: Disallow vvar access to vclock IO for never-used vclocks >> >> arch/x86/entry/vdso/vdso2c.h | 7 -- >> arch/x86/entry/vdso/vma.c | 124 ++++++++++++++++++++------------ >> arch/x86/entry/vsyscall/vsyscall_gtod.c | 9 ++- >> arch/x86/include/asm/clocksource.h | 9 +-- >> arch/x86/include/asm/mmu.h | 3 +- >> arch/x86/include/asm/vdso.h | 3 - >> arch/x86/include/asm/vgtod.h | 6 ++ >> include/linux/mm.h | 2 + >> include/linux/mm_types.h | 22 +++++- >> mm/memory.c | 25 ++++++- >> mm/mmap.c | 13 ++-- >> 11 files changed, 151 insertions(+), 72 deletions(-) >> >> -- >> 2.5.0 >> > > > > -- > Andy Lutomirski > AMA Capital Management, LLC -- Andy Lutomirski AMA Capital Management, LLC -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org