Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753744AbdLMSfC (ORCPT ); Wed, 13 Dec 2017 13:35:02 -0500 Received: from mail-ot0-f171.google.com ([74.125.82.171]:35917 "EHLO mail-ot0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753332AbdLMSfB (ORCPT ); Wed, 13 Dec 2017 13:35:01 -0500 X-Google-Smtp-Source: ACJfBou+V8UnxkesX662de802z/q6uGy7l6S1ndZ8M8gnhJ9wAULG9VFQj3tRhpAVXlMrglUf0NJPE1JMBnOzg7fJ5s= MIME-Version: 1.0 In-Reply-To: <20171213183209.GZ3165@worktop.lehotels.local> References: <20171212173221.496222173@linutronix.de> <20171212173333.669577588@linutronix.de> <20171213122211.bxcb7xjdwla2bqol@hirez.programming.kicks-ass.net> <20171213125739.fllckbl3o4nonmpx@node.shutemov.name> <20171213153202.qtxnloxoc66lhsbf@hirez.programming.kicks-ass.net> <20171213155427.p24i2xdh2s65e4d2@hirez.programming.kicks-ass.net> <20171213183209.GZ3165@worktop.lehotels.local> From: Linus Torvalds Date: Wed, 13 Dec 2017 10:35:00 -0800 X-Google-Sender-Auth: CqHeqjt-86B5lt7aZEIGfBg-CHg Message-ID: Subject: Re: [patch 05/16] mm: Allow special mappings with user access cleared To: Peter Zijlstra Cc: Dave Hansen , "Kirill A. Shutemov" , Andy Lutomirski , Thomas Gleixner , LKML , X86 ML , Borislav Petkov , Greg KH , Kees Cook , Hugh Dickins , Brian Gerst , Josh Poimboeuf , Denys Vlasenko , Boris Ostrovsky , Juergen Gross , David Laight , Eduardo Valentin , "Liguori, Anthony" , Will Deacon , "linux-mm@kvack.org" , "Kirill A. Shutemov" , "Aneesh Kumar K. V" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 675 Lines: 15 On Wed, Dec 13, 2017 at 10:32 AM, Peter Zijlstra wrote: > > Now, if VM_NOUSER were to live, the above change would ensure write(2) > cannot read from such VMAs, where the existing test for FOLL_WRITE > already disallows read(2) from writing to them. So I don't mind at all the notion of disallowing access to some special mappings at the vma level. So a VM_NOUSER flag that just disallows get_user_pages entirely I'm ok with. It's the protection keys in particular that I don't like having to worry about. They are subtle and have odd architecture-specific meaning, and needs to be checked at all levels in the page table tree. Linus