Received: by 2002:a05:6a10:eb17:0:0:0:0 with SMTP id hx23csp849334pxb; Fri, 3 Sep 2021 15:19:23 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyJiobQYUf9v1OPUEBrXWGUIkFWHECsgQm3v9pBllPlcq3yFnxPwz2E1vE4zRCz3LNpmM1B X-Received: by 2002:a50:ed09:: with SMTP id j9mr1216929eds.164.1630707563347; Fri, 03 Sep 2021 15:19:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1630707563; cv=none; d=google.com; s=arc-20160816; b=NaCDhnl7oR4T2U1+jqwwlwLc5p8FBlRAuKGCMwxABsOMwflzme3cHxESUp99BvIFk+ BYVPx0h9+H+MTgKb37vTKLyUEkZZ4Vm4O+X1+aoi8qZTmtEg+BmWXPEytQKCzjml8dOA zFbT8DNedA6hcM2ZjMG0zgdwZPWFX1Ysg89Q8vSMbHxLh2vY+zFnUyKlIblAfKlVVYWl g6/dTiuc12n0M4sOI9alMYuGT8X6zcTd6FItxn1Jb3t0NsV5OnapikOgsfgzHm5qEQ3l Tg/QLCW97/tWBnM3OWRVUeIyi+DBaOdB5u+pVwoslexWVbBeNrRVPODoHn1xxdkaCJqo P72w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=zG5/7AV9BzevEKzJQKSrnmTBIp1ROnBD6nq2xHoY4wg=; b=fvR2hdVf10l1rb3cH698FCeFL5Y4zCV7xgv7ZmqF148HQjAicgmmoMISFnp65hOt6W MSYIbEcPR/w8r2UWYjamKohT/suu8ZHTeES10DoSikrenutTX9ZWZ3EZTIveP9ELQPeQ 2aR5DrTHDkCQhta6781eQyrrZf8pllTtWSyf3TTBB4NF7Rt+9qasELwisWtdBrZ4PIyr 5MbUHOJqevqFSuJ4tAawO+pDmwvbKA8RjBPx/F8XL1mmpxXBPPosaugMgZKc+3oY5VFV wAUa7QKqUBpi1xQh67QTOMs6j8SY5pwZm9WdvxXNgTt093C6rmoRWrqmMsxXF8AeUTeo kQXA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=kFkSIiu5; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id j17si488216ejm.446.2021.09.03.15.18.57; Fri, 03 Sep 2021 15:19:23 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=kFkSIiu5; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235222AbhICV5f (ORCPT + 99 others); Fri, 3 Sep 2021 17:57:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57188 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236029AbhICV5d (ORCPT ); Fri, 3 Sep 2021 17:57:33 -0400 Received: from mail-yb1-xb31.google.com (mail-yb1-xb31.google.com [IPv6:2607:f8b0:4864:20::b31]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 30914C061760 for ; Fri, 3 Sep 2021 14:56:33 -0700 (PDT) Received: by mail-yb1-xb31.google.com with SMTP id j195so1067050ybg.6 for ; Fri, 03 Sep 2021 14:56:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zG5/7AV9BzevEKzJQKSrnmTBIp1ROnBD6nq2xHoY4wg=; b=kFkSIiu5R2dx6dF1mtriwDnLYB3riLPv3xSIambOd/wio1cGYvXWPu65Mk4C6WBuN+ mRcqBD34nOnJdi1ZkqeLWw6Al9MkAvElp6zXiUx/gZBqb1plytyUGRay7F72mEEyfHLw qPGLVGfxwreGIUCMBQ1dA24p/Nih73FDf5fMOSlNkcyu1zsiMYqYKM6xENDs9mRNSfrt qiaPu2cOc7NANF/FcEXMkaZEAu2abAIKsLtuf7xiDLmsv7SRB57+q3x3ErQl3ZfdGF+K mIrLanpaYYWSqCGILhdt06H1ZytO5wpkX8rf6ALNMKThmri0pCz2viNiA4S7KAEx0JSe sorA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zG5/7AV9BzevEKzJQKSrnmTBIp1ROnBD6nq2xHoY4wg=; b=n2NiCCIhjAcn0Mjl7Aj+6TpoIuZAyIlmdoUcV1z2s6P19eRw57o/RgKJq/3Odsf0En kYVFqHrldD3dllHotnmGntg8NPcwdopPIe6UfHLxeQYdcn7rqqhaxsPYLaptHRMIcxvc qzVfgZvA6UU80vzQdh1tihZ2sET3aVDQ9aoX1HF1ahhdHzMCdhGa6LhjbZk5i8VdP6+9 D0TRxNmImeRaTvPXscek6SOxnlA9D+tJHcRq4edcyxwKZS6qsuLdWwJJadpUm2iGyvD0 vRVx1cnRLliDusW2A9sN8Lb731we6C+l+k33qNCvqE/BCTZI8akRXq5lDvZ0wW5IlvpZ TPbQ== X-Gm-Message-State: AOAM533fC1HkNDK4m2owaeNKm1Pc8Qhcx7H+LHqhUUL8TE4ifTXlr0pX ILkhxQCQYgg9bomtFNZsZSRVu5Kt3oA/SNKRtrrbvA== X-Received: by 2002:a05:6902:1247:: with SMTP id t7mr1542942ybu.161.1630706192001; Fri, 03 Sep 2021 14:56:32 -0700 (PDT) MIME-Version: 1.0 References: <20210902231813.3597709-1-surenb@google.com> <20210902231813.3597709-2-surenb@google.com> <202109031439.B58932AF0@keescook> In-Reply-To: <202109031439.B58932AF0@keescook> From: Suren Baghdasaryan Date: Fri, 3 Sep 2021 14:56:21 -0700 Message-ID: Subject: Re: [PATCH v9 2/3] mm: add a field to store names for private anonymous memory To: Kees Cook Cc: Andrew Morton , Colin Cross , Sumit Semwal , Michal Hocko , Dave Hansen , Matthew Wilcox , "Kirill A . Shutemov" , Vlastimil Babka , Johannes Weiner , Jonathan Corbet , Al Viro , Randy Dunlap , Kalesh Singh , Peter Xu , rppt@kernel.org, Peter Zijlstra , Catalin Marinas , vincenzo.frascino@arm.com, =?UTF-8?B?Q2hpbndlbiBDaGFuZyAo5by16Yym5paHKQ==?= , Axel Rasmussen , Andrea Arcangeli , Jann Horn , apopple@nvidia.com, John Hubbard , Yu Zhao , Will Deacon , fenghua.yu@intel.com, thunder.leizhen@huawei.com, Hugh Dickins , feng.tang@intel.com, Jason Gunthorpe , Roman Gushchin , Thomas Gleixner , krisman@collabora.com, chris.hyser@oracle.com, Peter Collingbourne , "Eric W. Biederman" , Jens Axboe , legion@kernel.org, Rolf Eike Beer , Cyrill Gorcunov , Muchun Song , Viresh Kumar , Thomas Cedeno , sashal@kernel.org, cxfcosmos@gmail.com, Rasmus Villemoes , LKML , linux-fsdevel@vger.kernel.org, linux-doc@vger.kernel.org, linux-mm , kernel-team Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Sep 3, 2021 at 2:47 PM Kees Cook wrote: > > (Sorry, a few more things jumped out at me when I looked again...) > > On Thu, Sep 02, 2021 at 04:18:12PM -0700, Suren Baghdasaryan wrote: > > [...] > > diff --git a/kernel/sys.c b/kernel/sys.c > > index 72c7639e3c98..25118902a376 100644 > > --- a/kernel/sys.c > > +++ b/kernel/sys.c > > @@ -2299,6 +2299,64 @@ int __weak arch_prctl_spec_ctrl_set(struct task_struct *t, unsigned long which, > > > > #define PR_IO_FLUSHER (PF_MEMALLOC_NOIO | PF_LOCAL_THROTTLE) > > > > +#ifdef CONFIG_MMU > > + > > +#define ANON_VMA_NAME_MAX_LEN 256 > > + > > +static inline bool is_valid_name_char(char ch) > > +{ > > + /* printable ascii characters, except [ \ ] */ > > + return (ch > 0x1f && ch < 0x5b) || (ch > 0x5d && ch < 0x7f); > > +} > > In the back of my mind, I feel like disallowing backtick would be nice, > but then if $, (, and ) are allowed, it doesn't matter, and that seems > too limiting. :) It's not used by the only current user (Android) and we can always allow more chars later. However going the other direction and disallowing some of them I think would be harder (need to make sure nobody uses them). WDYT if we keep it stricter and relax if needed? > > > + > > +static int prctl_set_vma(unsigned long opt, unsigned long addr, > > + unsigned long size, unsigned long arg) > > +{ > > + struct mm_struct *mm = current->mm; > > + const char __user *uname; > > + char *name, *pch; > > + int error; > > + > > + switch (opt) { > > + case PR_SET_VMA_ANON_NAME: > > + uname = (const char __user *)arg; > > + if (!uname) { > > + /* Reset the name */ > > + name = NULL; > > + goto set_name; > > + } > > + > > + name = strndup_user(uname, ANON_VMA_NAME_MAX_LEN); > > + > > + if (IS_ERR(name)) > > + return PTR_ERR(name); > > + > > + for (pch = name; *pch != '\0'; pch++) { > > + if (!is_valid_name_char(*pch)) { > > + kfree(name); > > + return -EINVAL; > > + } > > + } > > +set_name: > > + mmap_write_lock(mm); > > + error = madvise_set_anon_name(mm, addr, size, name); > > + mmap_write_unlock(mm); > > + kfree(name); > > + break; > > This is a weird construct with a needless goto. Why not: > > switch (opt) { > case PR_SET_VMA_ANON_NAME: > uname = (const char __user *)arg; > if (uname) { > name = strndup_user(uname, ANON_VMA_NAME_MAX_LEN); > if (IS_ERR(name)) > return PTR_ERR(name); > > for (pch = name; *pch != '\0'; pch++) { > if (!is_valid_name_char(*pch)) { > kfree(name); > return -EINVAL; > } > } > } else { > /* Reset the name */ > name = NULL; > } > mmap_write_lock(mm); > error = madvise_set_anon_name(mm, addr, size, name); > mmap_write_unlock(mm); > kfree(name); > break; Yeah, I was contemplating one way or the other (less indents vs clear flow) and you convinced me :) Will change in the next rev. Thanks for the review! > > > -- > Kees Cook