From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id C5A03C3DA4A for ; Fri, 2 Aug 2024 14:59:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D87CF6B007B; Fri, 2 Aug 2024 10:59:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D38316B0083; Fri, 2 Aug 2024 10:59:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BFF8D6B0085; Fri, 2 Aug 2024 10:59:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id A36146B007B for ; Fri, 2 Aug 2024 10:59:25 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 4D58F41293 for ; Fri, 2 Aug 2024 14:59:25 +0000 (UTC) X-FDA: 82407613890.21.2CDA0B4 Received: from mail-oa1-f45.google.com (mail-oa1-f45.google.com [209.85.160.45]) by imf29.hostedemail.com (Postfix) with ESMTP id 76FE3120006 for ; Fri, 2 Aug 2024 14:59:23 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=WyWxGI5f; spf=pass (imf29.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.160.45 as permitted sender) smtp.mailfrom=jeffxu@chromium.org; dmarc=pass (policy=none) header.from=chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1722610686; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=7Fufy5m2OV5adnD39XIC3KOkSG897ehk5PnPWDRKTeo=; b=YVVherI4SP1SgTIVVPbGwj9H9oncjCuWxYo92n+uzyxxrUXFb1ejCoY028ABsZcCowkF3b ZW4feWjoeMYjJcLc4JMgEs5XUg+MxC6P9OxlnUWIXNejRI7FJ4JeQwUFioI7ciwYmgaurJ Kh/j2fTSn5E5ZCkOn/kWgPi8QjZkDZY= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=WyWxGI5f; spf=pass (imf29.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.160.45 as permitted sender) smtp.mailfrom=jeffxu@chromium.org; dmarc=pass (policy=none) header.from=chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1722610686; a=rsa-sha256; cv=none; b=h7GYSBwnM0JcG+hmzFJBdMDZkvl3QBy8sD1NJoUJ8ug51fQMbsvMmTUcjV3QVf+3Cubdfu hd0fMEjwuGPYyqS+3verHgzR0xDVq38O/J1uTbJHx7MgyUqXhYbHQo9Nd5+aaeaC84drMp P2baPwKjaA3kZAWZ0fa916Skp03Hn2Y= Received: by mail-oa1-f45.google.com with SMTP id 586e51a60fabf-25e397c51b2so5041651fac.3 for ; Fri, 02 Aug 2024 07:59:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1722610762; x=1723215562; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=7Fufy5m2OV5adnD39XIC3KOkSG897ehk5PnPWDRKTeo=; b=WyWxGI5fPKU07YpQXPibeiHCb9pD9ZqgZ3ZZOit4z/7vjOJcwiv23hrhQ26/bWPOOg LGH0xAOQhESs/SLqUhsUQsiijnvePVOSNEHe8ySqiwyFviy1W5rohYssZZurco8ZkCEq 6mAnYUb2YIoC0fYHvCUVgK+gNqWJQeRX9LHWE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722610762; x=1723215562; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=7Fufy5m2OV5adnD39XIC3KOkSG897ehk5PnPWDRKTeo=; b=aaq+JCZfKLj9MfghP9ildIdh6dDFUjW/S6MyYQKqclYd2kXIfJkpHccp/1X5MXEiBH itMMwtecrqULi8KgLqKvOnS3o8zYG3SgtNPEPbXQzwpiBd00YdtbAsbrTEvXX43kUOvl xv/eo6GMRVwLMikrumiqADn1PD7OqzId134ha6/hGudIUANpdieaBKURJ7I7siwXFOtT U/T3wFgIrucXYQoflPUOjaLiDPYp9xKdG9K+TINplz6zFaw/LnY98VkoAtoNCNhsf5wQ fPhhXdc5WGpZv2znJkbEsh/O3mUHxSCwITIcIsT1dS83gycx5VNPJjGK1O7Wp7bL4owo 6ivQ== X-Forwarded-Encrypted: i=1; AJvYcCXR1zm34oQHwfQMYHSTPxCl3/+NoOhz/QirMrgM5he6/PzbkuK/y3Qcwh+IwopLCfu69OhcJDLYP2Cprg0iBACqsSc= X-Gm-Message-State: AOJu0Yw7K0kI038ZxdsbSWiiqUu+twn34e3638jHa3rPJzZAFYlf9xuM TJyXstsGSGLi9s+sYj3u7kpTdQhilIdoEticfccEib9jjhdmWVmDH6YERc4VgSi/QPVQVys3J/u 7giPegOja0q/c67cmxyEnKiuzGpRoIg1xV9b6 X-Google-Smtp-Source: AGHT+IG7v+U440RJkotFtfTZE0KJzrQAJ//UGBiRZS6c0xmXngLp+KViHU3IZS02qx6h4QDwAuEDyYYE5rxrF9y/tYw= X-Received: by 2002:a05:6870:3913:b0:260:ec71:27dc with SMTP id 586e51a60fabf-26891f3ee4bmr4602532fac.47.1722610762244; Fri, 02 Aug 2024 07:59:22 -0700 (PDT) MIME-Version: 1.0 References: <20240802090040.GB12343@redhat.com> In-Reply-To: <20240802090040.GB12343@redhat.com> From: Jeff Xu Date: Fri, 2 Aug 2024 07:59:09 -0700 Message-ID: Subject: Re: question on [uprobes] special vma To: Oleg Nesterov Cc: Kees Cook , srikar@linux.vnet.ibm.com, Ryan Roberts , "adrian.hunter@intel.com" , "glider@google.com" , Matthew Wilcox , zokeefe@google.com, hughd@google.com, luto@amacapital.net, "jmarchan@redhat.com" , "rientjes@google.com" , Thomas Gleixner , Ingo Molnar , LKML , linux-mm@kvack.org, Andrew Morton Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 76FE3120006 X-Stat-Signature: mnrhj1osbcoyjhcaogjcza33o6xegiqz X-Rspam-User: X-HE-Tag: 1722610763-759659 X-HE-Meta: U2FsdGVkX18a2AW7F6zC0ChHNj37cukbIz7DTW+gd4kvJZjDaiy1tWxHaowdwZcVg5KVgysLuX3KPJCcKTvmRafQcqup1PFjsMVhFxMZqLUs1KmLTqla+QKub9banh0XIQg3Yq6WgfBNvxBEZqX5tAMvqjuySb2kwZTPE5f5adHfntGLkfKcxOrR8vr9A8x/nPH/FWqMtLPCJEIcctBYnUtU5wTnxHJbc4Et+WYdHYZ/f2s/dm1TfwzYGq+ofh5LiEVGyczLmQ/owrHDhQH+O+pkUYoyf3Y/AIPTL4X6h8GbxsLRSaeqjExQG46xAtWO74nCXkp+pwaFuJnmYKc0nLFb5vSW9vn4WljHT3nGCKs1D4pjrp5TjLFef/GFYR6TCnzCy1vuUmtAETTmBLQDNwJ2PdI/Za3J5fdaIFyytMGl7uBMEJlJPn4UW+SsyFw0KPHUY5AmME/JUFLTL7MOvJvF0LHXI3MCooo6BgmKmFzqLbIHHHQE4w7/a9uDY2BBPtGeUT04F1keJJ4XgHajYUMJ/ksd8H3hw57b6o6jVLeMnUm02wKtz6SWhGDnAXnakSiV3arVw3iADP+8GFcjxHCAZw08AleXS8HbHWCbBF7+TX/R0EuZAsIpVEoNzO3ZwDSLhXQmIUhYiqelgP2BF91hTHTzmNbqIKkRzr3D+c0Enlpz29r42v/doWpHc4RypomvTo+j7SMCw03OGCwbk72eH9GiWs7ajQ5fe8Xfg77r4h/cNRPdVamGWYPod0JW8e5RT41F4a6xZ1Aq8MIpSKUOCnR23K9zHCuprXj6kCfLLlHx4oDKM0tgRkTg2FHNGtyVTtmYn1kBpRkIOEFbJMTLPjT9wAAtXJQrnyXNSWa2pyZYOoNHesjdSzJtF0qaflgOX7BRuRYGtc0UjFhsRV3E/7vy0hH1EKLp5IdQgPQkM7HMERWCOo84NvVBPhtZQcT6+YcA1kDwIFg+JUY vQrxiE9x X9eINf0je5YWQrEZS3++9YyF57q2nGj1V4Tvq8pNvrRLtQgxuEkBhTI51xGvyVRjmz90l9U3WP3QN2k6OpMxmsM+iJ3QxeKa37w4wTTrnyCuSM6X8nLDE8dpsCOlMmyZ6H9gwcjUmSC/w86+l54Ix3v6ld9BJxopOx37gCaU2WDozblQbHiua5yyKZLHjYGICtAMAHsK7QtNCasItHQWLTa3j2oaldUZUl/CfBO2Bq6Gl1TqhQrSxtFNjGnwFsy8KzBXzqMDuTQh5Uxgw/eK0EO0uDRbvnutBdvTkw8rpvggZY88hL8YcjGOS/Pjekq/yfJaSP3KgrSZmN4/VvfY1cpO0V1/6CjiJPJL8Cu6EDEpuzbLX/G6KTS6VFffAplXgG4bBhYmiBbk6yygz8f/lTYyQLh9ON2SqLyM7NtBtJDPM65TK9hCRkjJDb5MdPhHNnNZy X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: Hi Oleg On Fri, Aug 2, 2024 at 2:00=E2=80=AFAM Oleg Nesterov wrot= e: > > Hi Jeff, > > On 08/01, Jeff Xu wrote: > > > > __create_xol_area() calls _install_special_mapping() to create a vma > > named [uprobes]. > > > > I'm trying to find out the lifetime of this uprobes vma, e.g. when it > > is created, will it ever be unmapped/remapped/changed during the > > lifetime of the process. > > > > If the uprobes vma remains the same during the lifetime of the > > process, > > Yes, > That is nice. > > I can call mseal on it so user space can't change it, i.e. > > blocking munmap/mremap/mprotect/mmap, etc. > > I didn't even know about mm/mseal.c... > The TLDR: once the memory area is sealed, mmap/munmap/mremap/mprotect/some of madvise will be blocked. https://docs.kernel.org/userspace-api/mseal.html On a related topic, Adhemerval Zanella has an RFC adding mseal support for dynamic linker. https://public-inbox.org/libc-alpha/20240731200307.2269811-1-adhemerval.zan= ella@linaro.org/ > at first glance do_mseal() just adds VM_SEALED for can_modify_vma(). > > So it seems that xol_add_vma() can just pass the additional VM_SEALED > flag to _install_special_mapping(), no? > Yes. Before I make that change, I want to confirm that [uprobes] VMA is immutable during the lifetime of the process, hence this email. > But why it depends on CONFIG_64_BIT? > It needn't, but the vm_flags_t in the vma struct for 32 bit is full, adding 32 bit support will make split/merge code more complex, (at one point of RFC process, 32 bit is included but later removed), If we like to have 32 bit support, perhaps we need to refactor the mm code to expand vm_flags first. Thanks for your help ! -Jeff > Oleg. >