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 9B5B5CFB441 for ; Mon, 7 Oct 2024 15:03:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 228896B0089; Mon, 7 Oct 2024 11:03:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 18C226B00AE; Mon, 7 Oct 2024 11:03:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 004836B00AF; Mon, 7 Oct 2024 11:03:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id D1BA56B0089 for ; Mon, 7 Oct 2024 11:03:36 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 84D8F405C7 for ; Mon, 7 Oct 2024 15:03:36 +0000 (UTC) X-FDA: 82647125232.22.0C64EB0 Received: from mail-ot1-f44.google.com (mail-ot1-f44.google.com [209.85.210.44]) by imf03.hostedemail.com (Postfix) with ESMTP id 9B3D62000B for ; Mon, 7 Oct 2024 15:03:34 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=aIFLO41I; spf=pass (imf03.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.210.44 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=1728313281; 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=XnMYpMSi30pRgprxZcWHtApA7E1/LbOK6iJZCnWy7fY=; b=c9QhQLvPK8A1eyAg20yhmAy3UzPXKeBrH9Uc8PouHocbHBBpGtuP0Bvw8aTW/ZAMlu0XI3 RhEixBsNg1z125ade1Pcn4QXv06s1a6vaGOpGwhf2P9h5IXIXKsC3gLoKkKG480y83a0/w 5PO2wxXkgTzweWlvswgS1fA8GfM4ImQ= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1728313281; a=rsa-sha256; cv=none; b=OJmJ/ZGmtY/So+W/y3otcXLwgP/W9R4y6cG5d8SdZ3ravR1IPJFjY4LbnsaQ+HGdQPQtlg mLjKQfWuvRii94i2raj+sUxTMkMXJAt7J6Ds2SKurcXpfNEZrZTKXhtqkc6FPIfHsM+E2Q 1VCGmdHQZnef8iP9rbJmHg9jLkay2nk= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=aIFLO41I; spf=pass (imf03.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.210.44 as permitted sender) smtp.mailfrom=jeffxu@chromium.org; dmarc=pass (policy=none) header.from=chromium.org Received: by mail-ot1-f44.google.com with SMTP id 46e09a7af769-7150faefe57so259334a34.3 for ; Mon, 07 Oct 2024 08:03:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1728313413; x=1728918213; 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=XnMYpMSi30pRgprxZcWHtApA7E1/LbOK6iJZCnWy7fY=; b=aIFLO41IyT4qD8UYvQIeQuHiQdFkeLkI8xS7G6UkwVrztVJ+KR3oXU0aMlsglyTnLL GHo5slqlPVD+POo4XOq7Xlbgp8pu1fMLMwe0HNGYl7dWId+S9lkan98ZPf7M+GEHnYm+ JyHahK2pHbwW0s6fLzi36RYgc6LqZj0CCIHco= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728313413; x=1728918213; 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=XnMYpMSi30pRgprxZcWHtApA7E1/LbOK6iJZCnWy7fY=; b=rBO+mlyWJVd04OIZ9ngiL52nvdOSRAJjMhRnVUW/aauDGne6908G697/AFbGLOXfFw wsnoEhBw+Xum9uI59BzrOsYphmo7mepuhQ52OIr3MUeDk3Sh6ULPX90LlsQ9MUp9UqIb xVMJcYOWJSUHe8L/zUTcHz4khlX3xZO8QLeRo7MYJ7IlS7F2NKZ57pyFv3EoyVF9ILea yoAJMUFHaD0fpas8dcRGme/30TLCgk/NIvKmkXsr4RbqydZwyfoVHIlRs1UrZ9lh4GRD MIx/NSLDmtYqmSITtIvZtIF/OWQ9QVSY2JoH+Ii88QLKpim0dS8bD+OLQjIrYGTShm8U 9vBw== X-Forwarded-Encrypted: i=1; AJvYcCVIXEjtFJI8Xo12ntzn/a+IgYDZ1a1yza9KGV5lJKewTNMUJgSDdniYG3PbBC+KUFJpyUQYwlINiA==@kvack.org X-Gm-Message-State: AOJu0YwmoFvh+2PeZrOubWAxj4JPlPivyso/80d0frpTAGDACRk1AQ9P 8NdbhkEuyt8NbEmJIaI4SIum0Wu3v9tKm9aeRXSPPhHlTU+oEb/Pk9RkAgaLiiyhOlwkHbgHf8x gAZ7cd9GVZiFAR44glKlwge08OUefK6BO47ED X-Google-Smtp-Source: AGHT+IHoAnc3BjGBILjnmbLFo2ofO9yLKDc28NITtzSSbSlwUCHw83CVP6hL/oqAJSRlAtNEV3l5YeF2ABjLV48sw9s= X-Received: by 2002:a05:6870:8a2a:b0:260:e5e1:2411 with SMTP id 586e51a60fabf-287c1e57f76mr2249422fac.6.1728313413483; Mon, 07 Oct 2024 08:03:33 -0700 (PDT) MIME-Version: 1.0 References: <20241001002628.2239032-1-jeffxu@chromium.org> <20241001002628.2239032-2-jeffxu@chromium.org> <4544a4b3-d5b6-4f6b-b3d5-6c309eb8fa9d@infradead.org> <78f05735-cca3-491e-b2d6-c673427efa07@infradead.org> <15868.1728090271@cvs.openbsd.org> In-Reply-To: <15868.1728090271@cvs.openbsd.org> From: Jeff Xu Date: Mon, 7 Oct 2024 08:02:00 -0700 Message-ID: Subject: Re: [PATCH v2 1/1] mseal: update mseal.rst To: Theo de Raadt Cc: Randy Dunlap , akpm@linux-foundation.org, keescook@chromium.org, corbet@lwn.net, jorgelo@chromium.org, groeck@chromium.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-mm@kvack.org, jannh@google.com, sroettger@google.com, pedro.falcato@gmail.com, linux-hardening@vger.kernel.org, willy@infradead.org, gregkh@linuxfoundation.org, torvalds@linux-foundation.org, usama.anjum@collabora.com, surenb@google.com, merimus@google.com, lorenzo.stoakes@oracle.com, Liam.Howlett@oracle.com, enh@google.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 9B3D62000B X-Stat-Signature: 3h4m8scdp39trgmcgpnq1yxj6ntt837t X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1728313414-53435 X-HE-Meta: U2FsdGVkX1/nv5q64RnWFztSpDK4NziTrefrL+2m8imID0/Vm2mu6gDs4Kay0u2bE40DtjM0gzTbVJ18cti80FuBtBfHl7HWIwsoc879b2kaym0FHPxDDmChh0HPggZVKF0ZuXlF3h22s7TjyBmdkGHhc08bJRzAHiB9zVuOuUE5bvWKhm3VRu+QH1oHWhdCGWjnMXkoGMYg68B2fJe6NYU4w9xAYI85g33w7B1d0Waf7szx1qfDzwr9PkoVdDWAyutYVwsxkjKCEQRYUB71/AGnYa6BMGBG90W7ywB1SqdWUsoRod8slU9zH2jd/IZfFNz6EfyzEZqdAKv9KhAztmGf7SidPFhDO/CV6gL3PzrLUZUm5cbiLGmyAnC0VZvpAe9/Mme1KAzklHXybFK/p1+ItpaY3IUCTxmAajXuz87XRawb+cUDOZcleiOp5LFWm+l2/8JLVOFydz/hkdwMpgPMlFjzPwXc5x5dP21fPjfKdDY5kLISyyzQM897IA7qBbCr3fwAft0sGIqxXjXqMssEm63UX6H8RfiJfCSC8/C2e4oeYJ+IdEbwlqddK/3TeLzliFTuWLZq/5GceGL4FauvnZFJx/SAxNdGhOMsoOnJ9paLwaRtrFMIhs4uV0KsXggXMcxATu0VtKKIr6dzRcEnoppxsBFVM2/LTGdGEojgw4G2ACT+9R9rJLPZeWaI4zOU4hd6yYIE9aoAyMngkyGA3w/O5AlTKpmANYUqmXvIAZMo/rwTBvk9UL3lZH9uuaSufsozZxvyFl7aJm26a1ANDaNONa8uJE7FQWOmfjCv/AHLXqvjwQ5QFjTTzXsiXtm8oj6xnoCQbi0dyjlyCsXzR2N+XbUN4guCUeb0//FWfEJNNndKPylk1X/fxUWpWceF677X5sXj659Rh7vamu/YQ+P1aYgToMwCEbekxDpZf70Kxc1XfWYyS+UUjeaOMBxYUlwdyPCAD5g0noe dYS0bx1F RMF9c7aKhu8ccxPfo+i00h5WLmLfLBDw73qGhd0voCpS6WseiN8Jk9H0ND85l0O1lHuK4Y+lPm+HJagXOePvWQ5WwkxxOfcKNC3eVQuBV554ip3LQmPuLCaFneBkTA7szTA8srXLtGDTmaN/tJSvtHw3Kc6/XaiXj8eKPanlMJAN2ZWw71bq5yPybKZ8PDYPOrLv1OL7rzAmR2j8jRhtn1AfuiQG6eZGD1LdMh22uS3nKh0rzXtVkrMzNYPUJCpdq+/B+0krHLczdSOHP4yw75mGL5PhrcfhdIlS3dlCsF9jGGspaMDtOAN3PBaS4Ip8gfZwpL3DxBsliSPcVO1t2ND+7INVuHJgoryPSyZHwSQECV1nCMwzuPHl0jeW+kE4X/h2c X-Bogosity: Ham, tests=bogofilter, spamicity=0.000177, 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 Theo On Fri, Oct 4, 2024 at 6:04=E2=80=AFPM Theo de Raadt = wrote: > > Randy Dunlap wrote: > > > On 10/4/24 9:52 AM, Jeff Xu wrote: > > >> above is not a sentence but I don't know how to fix it. > > >> > > > Would below work ? > > > > > > Certain destructive madvise behaviors, specifically MADV_DONTNEED, > > > MADV_FREE, MADV_DONTNEED_LOCKED, MADV_FREE, MADV_DONTFORK, > > > MADV_WIPEONFORK, can pose risks when applied to anonymous memory by > > > threads without write permissions. These behaviors have the potential > > > to modify region contents by discarding pages, effectively performing > > > a memset(0) operation on the anonymous memory. > > > > Yes, that works. > > Or at least it explains the problem, like Theo said. > > In OpenBSD, mimmutable() solves this problem (in later code iterations). > > In Linux, does mseal() solve the problem or not? The statement doesn't > answer this question. It only explains the problem. > > If it doesn't solve the problem, that's pretty surprising (weaker than > mimmutable). > > During development I wrote a fake little program which placed an 'int =3D > 1' resided into a zone of readonly memory (.data), and then imagined "an > attacker gets enough control to perform an madvise(), but only had > enough control, and has to return to normal control flow immediately". > The madvise() operations was able to trash the int, altering the > program's later behaviour. So I researched the matter more, and adapted > mimmutable() to block ALL system-call variations similar to 'write to a > not-permitted region'. > > So the question remains: Does mseal() block such a (rare) pattern or not= . Apology for delay. Yes, mseal does block such patterns. Thanks -Jeff > The sentence doesn't indicate that mseal() has a response to the stated > problem. >