From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752095AbdHJHOJ (ORCPT ); Thu, 10 Aug 2017 03:14:09 -0400 Received: from mx2.suse.de ([195.135.220.15]:42024 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751391AbdHJHOH (ORCPT ); Thu, 10 Aug 2017 03:14:07 -0400 Date: Thu, 10 Aug 2017 09:14:05 +0200 From: Michal Hocko To: Jerome Glisse Cc: Igor Stoppa , Linux-MM , LKML , linux-security-module@vger.kernel.org, "kernel-hardening@lists.openwall.com" , Kees Cook Subject: Re: [RFC] Tagging of vmalloc pages for supporting the pmalloc allocator Message-ID: <20170810071404.GD23863@dhcp22.suse.cz> References: <20170803151550.GX12521@dhcp22.suse.cz> <20170804081240.GF26029@dhcp22.suse.cz> <7733852a-67c9-17a3-4031-cb08520b9ad2@huawei.com> <20170807133107.GA16616@redhat.com> <555dc453-3028-199a-881a-3ddeb41e4d6d@huawei.com> <20170807191235.GE16616@redhat.com> <20170808231535.GA20840@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170808231535.GA20840@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue 08-08-17 19:15:36, Jerome Glisse wrote: > On Tue, Aug 08, 2017 at 03:59:36PM +0300, Igor Stoppa wrote: > > On 07/08/17 22:12, Jerome Glisse wrote: > > > On Mon, Aug 07, 2017 at 05:13:00PM +0300, Igor Stoppa wrote: > > > > [...] > > > > >> I have an updated version of the old proposal: > > >> > > >> * put a magic number in the private field, during initialization of > > >> pmalloc pages > > >> > > >> * during hardened usercopy verification, when I have to assess if a page > > >> is of pmalloc type, compare the private field against the magic number > > >> > > >> * if and only if the private field matches the magic number, then invoke > > >> find_vm_area(), so that the slowness affects only a possibly limited > > >> amount of false positives. > > > > > > This all sounds good to me. > > > > ok, I still have one doubt wrt defining the flag. > > Where should I do it? > > > > vmalloc.h has the following: > > > > /* bits in flags of vmalloc's vm_struct below */ > > #define VM_IOREMAP 0x00000001 /* ioremap() and friends > > */ > > #define VM_ALLOC 0x00000002 /* vmalloc() */ > > #define VM_MAP 0x00000004 /* vmap()ed pages */ > > #define VM_USERMAP 0x00000008 /* suitable for > > remap_vmalloc_range > > */ > > #define VM_UNINITIALIZED 0x00000020 /* vm_struct is not > > fully initialized */ > > #define VM_NO_GUARD 0x00000040 /* don't add guard page > > */ > > #define VM_KASAN 0x00000080 /* has allocated kasan > > shadow memory */ > > /* bits [20..32] reserved for arch specific ioremap internals */ > > > > > > > > I am tempted to add > > > > #define VM_PMALLOC 0x00000100 > > > > But would it be acceptable, to mention pmalloc into vmalloc? > > > > Should I name it VM_PRIVATE bit, instead? > > > > Using VM_PRIVATE would avoid contaminating vmalloc with something that > > depends on it (like VM_PMALLOC would do). > > > > But using VM_PRIVATE will likely add tracking issues, if someone else > > wants to use the same bit and it's not clear who is the user, if any. > > VM_PMALLOC sounds fine to me also adding a comment there pointing to > pmalloc documentation would be a good thing to do. The above are flags > that are use only inside vmalloc context and so there is no issue > here of conflicting with other potential user. Yes I agree. VM_PRIVATE just calls for the issues you are dealing with at struct page level where you simply do not know who might be (ab)using mapping and what not because the naming is just too generic... -- Michal Hocko SUSE Labs