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 1AB72C04FFE for ; Wed, 15 May 2024 02:59:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 73E778D0067; Tue, 14 May 2024 22:59:01 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6EDA48D004F; Tue, 14 May 2024 22:59:01 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5B5558D0067; Tue, 14 May 2024 22:59:01 -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 3493E8D004F for ; Tue, 14 May 2024 22:59:01 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id BFBD4A13C8 for ; Wed, 15 May 2024 02:59:00 +0000 (UTC) X-FDA: 82119123240.07.62D6407 Received: from 1wt.eu (ded1.1wt.eu [163.172.96.212]) by imf21.hostedemail.com (Postfix) with ESMTP id 715AA1C0004 for ; Wed, 15 May 2024 02:58:58 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf21.hostedemail.com: domain of w@1wt.eu designates 163.172.96.212 as permitted sender) smtp.mailfrom=w@1wt.eu ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1715741939; 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: in-reply-to:in-reply-to:references:references; bh=1DYSGIEVFDiRjWKV8Bo36Ee7DbDPljLKB+uhL4xgVv0=; b=spdlq3WgRDdwyWMTCLo3y8vPzj/4aDL5a9w1AyQDNf9MEEXNsFD8iT4AnoWCK6oEnEs/Yi 5IHBNVpwvFFRzWXC/FFOifTut7QxUYRAoPZ6eTqCAYX1xh7r5yW7dT8CuVJF0gwdPNiX9j 8tiLLHl81/JQYHfTk9JnChB/KRc9fUY= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf21.hostedemail.com: domain of w@1wt.eu designates 163.172.96.212 as permitted sender) smtp.mailfrom=w@1wt.eu ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1715741939; a=rsa-sha256; cv=none; b=W9ykovLhkTTZIupOzJ2pb6CkA02z5S57bRqgSjHjAxHlwoVjEMoDq+dQgblyGZhFQioI1t caG51NT+yZZC3+cyLhoeH/Rspb7/Nwx75q4LQp09hB0jSu4M83x2XqYsZYGYrNjgTuLJuu wB5CcreK1ym4oVrjqNpG1zJjCHXg/sE= Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id 44F2wB5O001379; Wed, 15 May 2024 04:58:11 +0200 Date: Wed, 15 May 2024 04:58:11 +0200 From: Willy Tarreau To: Theo de Raadt Cc: Andrew Morton , Matthew Wilcox , Jonathan Corbet , jeffxu@chromium.org, keescook@chromium.org, jannh@google.com, sroettger@google.com, gregkh@linuxfoundation.org, torvalds@linux-foundation.org, usama.anjum@collabora.com, Liam.Howlett@oracle.com, surenb@google.com, merimus@google.com, rdunlap@infradead.org, jeffxu@google.com, jorgelo@chromium.org, groeck@chromium.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-mm@kvack.org, pedro.falcato@gmail.com, dave.hansen@intel.com, linux-hardening@vger.kernel.org Subject: Re: [PATCH v10 0/5] Introduce mseal Message-ID: <20240515025811.GA1232@1wt.eu> References: <20240415163527.626541-1-jeffxu@chromium.org> <20240514104646.e6af4292f19b834777ec1e32@linux-foundation.org> <871q646rea.fsf@meer.lwn.net> <56001.1715726927@cvs.openbsd.org> <20240514160150.3ed0fda8af5cbd2f17c625e6@linux-foundation.org> <92453.1715730450@cvs.openbsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <92453.1715730450@cvs.openbsd.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-Rspamd-Queue-Id: 715AA1C0004 X-Stat-Signature: skkaqf6gac5sawurps79nxiq4mtz53nu X-Rspam-User: X-Rspamd-Server: rspam11 X-HE-Tag: 1715741938-441964 X-HE-Meta: U2FsdGVkX19LdQKK5xeVuPYpWQfT3Qh4TFcIvqOZ8TVZ4/TEqbingCofFHdLFHcrFeSWEZ3pb6o7tnWg7xTPEKpFufircZbQ6egeTPjxwZJ3YsXmGdVE0V7ogK4/5mxLMtLdwj4BKfhpQJfvRXBftW4mCcz05rOdvPqdSvRU58lr7B4pSmDZke4kKCLPmOjWVgx/nmymNhHyKW4kozEnUyztakW0SYbe8ZA540dVb1H+1X/036sDVYJfZZy/gCymkxkjisY5Fvr4Uham5YgbWX3BirT3RkAV+TAEzhoKagneulsdtoqNkxV45Wgb3KG1wVHSIt3pRSn+AWZiaWHclJizg0Mau6M7E5iiMhpCm8NTIG6O1rPxfEQ9uQ9W3Qep/Fdueeq/AdudBMvfVFmB8nw6A+I17Mw9QvKEg/BcrQw+H6JFi9lCWvPwwywXCxglgfpNxHoylVerKkoMrt1vGhRkiliNfHhPW/vM2qEKv02EkrLh+pOK2LrudkKCLo5DC13HrhK1ItXEEJXs79GT9qTHorWnFmQDR1YMIeesjwafX7tuLLfC/6LVstnncrbiBNYiMc0/FT75HPPNHSAIo0VTLssIK8ycANabYxoQ2bUsEY0uS5U5GZamCs41+foAR3IA+I4CVUAL84q11IJIXpClOU6qynY+6WmhdyjZCsAzCyw0eOaycwafrY1kqUmEZV5sFbmwbGslsrdm+dx/6DVuhSc8fK53x1jnRDDGSrbmcopT+qo2l/GVHVoM+tpnMNmKE5DJ604MODJD6bg9D9WhZ3Z8IvrQ0B5L6R0VykQOmY2aB0A2tXo4yITw6EQm+j3FVptjnqAd89Z0E2VhdPc/NCP21jcTltTMZP2OkHjpMfsbeiBwumtAx0H2zddzacCkGdsCr3ch5W5aJg1n8WLU/5giLc1gJO5yJ8Z3+AZDfKgMFRyULrFSMW7P66+hCkD3yQb6mVagtie96tT fQOCTIJy dWT9YQmU6APj2fihKaOqmZJs3zxhF20qMb7Z8mzPavhmVjlfDFsJ1hRrJxlCltS/A52YLZHOPm+Pdgk2/+/bl8AYRIMTOUc5X74bGR9hER543maV/bVtcGmBzj/ePOzLHVWrQVPUZnGbeJvAsJKLWuAFRJg== 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: On Tue, May 14, 2024 at 05:47:30PM -0600, Theo de Raadt wrote: > Andrew Morton wrote: > > > > I worry that the non-atomicity will one day be used by an attacker. > > > > How might an attacker exploit this? > > Various ways which are going to be very application specific. Most ways > will depend on munmap / mprotect arguments being incorrect for some > reason, and callers not checking the return values. > > After the system call, the memory is in a very surprising configuration. > > Consider a larger memory region containing the following sections: > > [regular memory] [sealed memory] [regular memory containing a secret] > > unmap() gets called on the whole region, for some reason. The first > section is removed. It hits the sealed memory, and returns EPERM. It does > not unmap the sealed reason, not the memory containing the secret. If we consider that the attack consists, for an attacker, in mseal()ing the beginning of an area to make sure to pin the whole area by making a future munmap() fail, maybe we could make munmap() not stop anymore on such errors and continue to unmap the rest of the area, for the purpose of not leaving such a theoretical attack vector work ? After all, munmap() currently skips wholes and continues to unmap the area. But then what would prevent the attacker from doing mseal() on the whole area in this case, to prevent it from being unmapped ? Wouldn't it be more effective to have a non-resettable prctl() allowing the application to prefer to be killed upon such an munmap() failure in order to stay consistent and more robust against such class of attacks? Willy