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 15067C3DA4A for ; Fri, 9 Aug 2024 18:45:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 82C0C6B008C; Fri, 9 Aug 2024 14:45:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7DB7A6B0092; Fri, 9 Aug 2024 14:45:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6A3256B0095; Fri, 9 Aug 2024 14:45:31 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 47FC56B008C for ; Fri, 9 Aug 2024 14:45:31 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id BBD53A811C for ; Fri, 9 Aug 2024 18:45:30 +0000 (UTC) X-FDA: 82433585220.30.A1942B4 Received: from mail-vk1-f178.google.com (mail-vk1-f178.google.com [209.85.221.178]) by imf30.hostedemail.com (Postfix) with ESMTP id F03F880014 for ; Fri, 9 Aug 2024 18:45:28 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=iLv09fq2; spf=pass (imf30.hostedemail.com: domain of pedro.falcato@gmail.com designates 209.85.221.178 as permitted sender) smtp.mailfrom=pedro.falcato@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1723229040; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to: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=9/p3SylQpex58YQMjwfSJg89oiO/p4Q8CMC4t6aIxTw=; b=nbmp73Iudv1QXfPaNtRigHuF8KY/SydGLf318h9AVz3WGGrn51g6VckbPu/aCCA/8yA3Dk sHH4qX+1tRnZC2KhdrNkqdhTk3Rl8lDzypKoGtufm2beg0vEpWT5FK1VqzGnif77QIc/dm UXLLyGW3VqePPaZbdacjXDmGdHwQrGs= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=iLv09fq2; spf=pass (imf30.hostedemail.com: domain of pedro.falcato@gmail.com designates 209.85.221.178 as permitted sender) smtp.mailfrom=pedro.falcato@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1723229040; a=rsa-sha256; cv=none; b=Xr3drwUW9AFptkJurbZ4y3NhXp37JJjTXNJMEIBPIf4iqaasUxUWk9WgX/EqZaxNU+ELnL xd0AVwNvfdwvo5G3kpZmvCdyINwaItFTCrO+h1JGfAnJiWqydFUCkaa1Iytfnxr0dxy7dF XgQYXMLlvyTe9a72lu1FSWlFLtw4Bvw= Received: by mail-vk1-f178.google.com with SMTP id 71dfb90a1353d-4f521a22d74so688300e0c.2 for ; Fri, 09 Aug 2024 11:45:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1723229128; x=1723833928; darn=kvack.org; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=9/p3SylQpex58YQMjwfSJg89oiO/p4Q8CMC4t6aIxTw=; b=iLv09fq2scy1rfhtpi9MZwTmqUmU1gzqiJWSp94Wan2U1MKPLqvaNjlfdBjyEwcNAI UG5B1oezCCimmXf8lhnnKsn5wSnz2p/YpzhoV8sXxmYQrGIu6VI8FUOInkIifovIQea4 xSbMcvn2Q2Zv5soNnW4KPXxyPh3aEZyl24GIXGIEvTZwZbnzCGu4EOGU1qzukXuqsD5J 9qe5OjRmY+qzQHQXkJ9mFZTkUpF7xAMw13KHY7eGz9uGyFG1rQJ++SUznEfadd+bqBlD bnxbpuVjsogzknxIPJhQWNpCPRJcs5Casq2V9GWzKQjmaWydae9IeslWmAoOXOgNMPPf b5YA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723229128; x=1723833928; h=content-transfer-encoding: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=9/p3SylQpex58YQMjwfSJg89oiO/p4Q8CMC4t6aIxTw=; b=CSD7Mxv+oT6jLdsli2qmgOEodIKTSwY9Kcyi3MHRr/2nX0DuwFciOK+2KgjYGTsIzW ST8SVIY1A7n7SdCUELHH603YNPylG8mnKg2tRcqpXMKWyGlQWt4Rc/TPlI7UjceWRbV8 U3sW4hUoV8rMV1mIZRKyWVrVUW5a5jx6C68lWXmX5i4Kv7/UvjYroHUIdEWc5uZ1Z6NT I0UTZi/iNCK+qtiQftao2oLu3srnrFnaQ478J1TOL+1aujaJt4+HK57bvNmEJ7iP0C2I XFc/Jp+ujJC2P4mOnM75qX84YLE2CZO5pKENEAWJuvJjpBPh10l2VoR5vDvr3LoopFz3 FKGA== X-Forwarded-Encrypted: i=1; AJvYcCXOKly3bTQOJmrhhzJcNYR+3lawHCrakQwnDl+8EiIlvVyGp/79NQuLr8kYRUdg/lVHoUMeBhNOl8TJciBQC0xGypI= X-Gm-Message-State: AOJu0Yy9zYVbkp5GWShG6LCk+rygxOVVt+Y7tpQ0vNnaoCsKKni2WyaE 21tkEvVILip62k2eDQn1dlWJNrVEOnnpGK0Dbziq9ICjUBgnzxmyRNjxtVnrDvToJCev3NT6UqA u0KNihZwOhjcfsUBPe72RU657Owk= X-Google-Smtp-Source: AGHT+IGO1JCPOBeO85kZqWEF9K7sRPfiwZEmC5y22fviesmzsajPdFAWbt4mXA17JwJ6hPn+zWBwbY5hOwUA9ilsVcU= X-Received: by 2002:a05:6122:134e:b0:4ed:52b:dd29 with SMTP id 71dfb90a1353d-4f912eecd0dmr2917204e0c.3.1723229128034; Fri, 09 Aug 2024 11:45:28 -0700 (PDT) MIME-Version: 1.0 References: <20240807211309.2729719-1-pedro.falcato@gmail.com> <20240807211309.2729719-5-pedro.falcato@gmail.com> <52wapi4gdnh3i2oiyk44utrco4ck5zph5mikoejfjrlfz2pwhe@eyiaozi4q23x> In-Reply-To: <52wapi4gdnh3i2oiyk44utrco4ck5zph5mikoejfjrlfz2pwhe@eyiaozi4q23x> From: Pedro Falcato Date: Fri, 9 Aug 2024 19:45:16 +0100 Message-ID: Subject: Re: [PATCH v2 4/6] mm/mremap: Replace can_modify_mm with can_modify_vma To: "Liam R. Howlett" , Pedro Falcato , Andrew Morton , Vlastimil Babka , Lorenzo Stoakes , linux-mm@kvack.org, linux-kernel@vger.kernel.org, oliver.sang@intel.com, torvalds@linux-foundation.org, jeffxu@google.com, Michael Ellerman Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: F03F880014 X-Stat-Signature: sxxeyo15qgfdue591te8qssrrysgq7it X-Rspam-User: X-HE-Tag: 1723229128-775880 X-HE-Meta: U2FsdGVkX1/8uOVIClituJVYhS/RDkbm/YPG4KBt6cCdWofXFZYDhu4Ec9v9uN+I7dLwQwS0ZvrL+6g6nOtPcS3ozm4BWTKRspNFfpQUTwF46/lAKmvIiXzcPO08yL90WjWWLgqGY/frmTnoUjJjY8o1pDZ6eqeRaeQ3+DQB5TOvTR/4sTdXEv8U9cV7iFlG0hQFpJKBnYbLE7xCwufEspSw5j7nxnL+khvx1QA8dWy2TDY/alrk3q/4eiNwLx016YnAx24PNpvZ1Br3SASk8Q46TCdzhvTT2z9p76qpDN44nCeQN3ScZ25Kcm+DtZx9QeIDvvXxwGjN+1yF+MgaqJEipg3q3+Q0/XUFYReYr01ch1i6gM+ONl/+oncDw4Nj9WaDycTX1ZA+dGAJOaXHZaRasXnyF6cCzQwBmDrirzgHSIkPuX0vZHpKGQmBA4gNLF8fv/9zjBh4vLB4WelJJFXGFCY3e2s//e6BqyuyVeG3V/9niodqglZid5hq9VKMy64cHbPiRJ/WmR0GL32vSDOS5OOf5EV7RTNJN+f1/rI8Pcd/IYfQ+XUOgSCNJ0U/Z0y2j03fcvuWyM/xVRl7hy0xSllOBdciLmW9viKXGERT3UC+OUIPlIppEGyL/mHoaKSy1a4F23q8TLvXDHTavLopzh7heck4aALRircBwujlT0qgJv0YGv+91nYEHQbc+hIOZKB27Rjt47iP2B3XMPSOm/hE40OB2h6QQ0qCFxBqbk4+blMyn8DXYHrbytaw+s9y/+u0y9lnjp+5zKUhxQqYOqCIyO9M8Xc8hXgg0Wj2XUCWEHmZGIQkmm1bRY5WoJlpepEOGLr5r5nl5ev+BO80xqJ9qDM4hZfMRYbqJ2xnrLkmdvdJxXIM+pTI5jlAK+SbrAyh9bV7XxKA4rAT5NmD2DWjekZJBO6hlL/xiYH9KF8lPT0y9SwnrtCZdvzuhPxqJ/21NE3diYnTo4e SYxJTACV ST1ra4KzSkY5/Kfewq0xCdHdYrFdaagm7wKiFyeF+O63SOIqwsVHmoZllkzuqdWMmtQJZSUwUenIkyq6+TpwHtWoriHcCkdCOIJi1EWl77iPiwUA9XZwMbksPJqj3L1T+rfhkl1Mnn+CQAAVDxH9NtTyejiSczwxDJ9lHW6dLirUWeMHjDWu4kAPguUhEVc9QHsLjZitzUw7JfFq+O6EjJqLA2881WJds56j9xRBZF7vsuUIUcm3mGvsk/FB91gBGbZlpXj+GweksIotvPUrRJlHuxeWbmkeKF5RU7wUlFcUgM1g3Hz6yKvERBgZCRNkyoq5OOEfcXURBydJAPvj12l4j5kE0Ge5DTikIg9HPKc/T2BB/0c7I+DjyYsPSlG/qcRJl9qg0bpO55XE7538tIoDRphKyM7Yh6OJTK9t6rKD2hKPxm9+S9Kge2HURaJYnR5Mix8rny1zKR+nRpbpfECHdbI8DgEPO/2TiA7buaDmn1X8= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000002, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Fri, Aug 9, 2024 at 5:06=E2=80=AFPM Liam R. Howlett wrote: > > * Pedro Falcato [240807 17:13]: > > Delegate all can_modify checks to the proper places. Unmap checks are > > done in do_unmap (et al). > > > > This patch allows for mremap partial failure in certain cases (for > > instance, when destination VMAs aren't sealed, but the source VMA is). > > It shouldn't be too troublesome, as you'd need to go out of your way to > > do illegal operations on a VMA. > > As mseal() is supposed to be a security thing, is the illegal operation > not a concern? My 3 cents (note: I'm not a security guy): - Linux m*() operations have been allowed to partially fail for ages. POSIX only disallows this in the munmap case (which is why we need all that detached VMA logic), but not in any other case. We have a lot of other failure points in these syscalls, and would require extensive refactoring to patch this up (very likely with an inevitable performance regression, as we saw in this case). - Despite allowing for partial failure, this patch set always keeps the sealed VMAs untouched (so that invariant isn't broken). The munmap semantics remain untouched (and POSIXly correct) due to the detached VMA logic. - I personally have not heard of a single attack making use of this, and the performance hit is very measurable and exists _for every user_, despite mseal being a very niche feature (I cannot find a single user of mseal upstream, both in debian code search, github, chromium, v8, glibc, and what have you). I remember SIGKILL on a bad operation being a possibility during the mseal patch set talks, and if people are really scared of this partial stuff, I would guess that's still a possibility. There are no users after all... --=20 Pedro