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 37DAEC4828E for ; Fri, 2 Feb 2024 21:02:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C51676B009D; Fri, 2 Feb 2024 16:02:53 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C022D6B009E; Fri, 2 Feb 2024 16:02:53 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AA33C6B009F; Fri, 2 Feb 2024 16:02:53 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 9B84E6B009D for ; Fri, 2 Feb 2024 16:02:53 -0500 (EST) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 5BF4B1C19E1 for ; Fri, 2 Feb 2024 21:02:53 +0000 (UTC) X-FDA: 81748088226.24.9808807 Received: from mail-oa1-f51.google.com (mail-oa1-f51.google.com [209.85.160.51]) by imf06.hostedemail.com (Postfix) with ESMTP id 7A068180023 for ; Fri, 2 Feb 2024 21:02:51 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=SjlAu6ZA; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf06.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.160.51 as permitted sender) smtp.mailfrom=jeffxu@chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706907771; 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=Kwv1t/9P2eD8k32faLH8OAi3mAtA+or2AT1hGZahOn0=; b=wYqW4/LupzvUyXqxp1FeF3z7ttNR7MdR6zF7HYPVDZmfp62kV6fUzXds20gR6SrHdwoLPF RtcosUlLHjnGDs8wlHatE+EKyZHA501Pm0GZ5zHFs9rJH2/UuC8bkvnkdTcRokbm1Sd52t RDXMUt5QVfT8+w7xbgabz41U/ZjzGpU= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=SjlAu6ZA; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf06.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.160.51 as permitted sender) smtp.mailfrom=jeffxu@chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706907771; a=rsa-sha256; cv=none; b=Dy1YhLlKfjn9wsuWM21aqEW/VQ3m8cAd7JL2LWX2OK4CNmhMn12IGBNL0/U3AZqB2utpMW caqnW78HzmkWU689DFzmEGQIoNI0h4ajaADB271c5bpYMQD1an7FaYBlBvDmWCYqAYpuBo HzHMpdp0TPhcnoDpAmKC8LmYaEaJTsg= Received: by mail-oa1-f51.google.com with SMTP id 586e51a60fabf-2185a9966bcso569651fac.0 for ; Fri, 02 Feb 2024 13:02:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1706907770; x=1707512570; 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=Kwv1t/9P2eD8k32faLH8OAi3mAtA+or2AT1hGZahOn0=; b=SjlAu6ZAMCUCENqwTnptqYiCMqi0Lm6rpNBEW7xfxdQ8ZqDznzw4H29q5Zktyh7/CW YdQ6VCLCuzYKgMgiSeq1x+UQiMd0gRz5OKCKOBYgRdv5D2SnPKiogHxptjEKHP1lZ9/P DQpwMtWoMQjkRf5hcBeFdpN/1o1OKXGB0ervk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706907770; x=1707512570; 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=Kwv1t/9P2eD8k32faLH8OAi3mAtA+or2AT1hGZahOn0=; b=oIKAYvSmYEO8UJJyUfCmmhpEa1h6KY71gK6nw+kw5XeF4bkJF/CVIz6f7puAggmnSI 9/7jEw+6ocx2RTSeA6BzQTLJHENlFDsYciDHY0vTcDSPKWyVBQnm1Xuh3hc3dLOXe3wz Iigi5dMwKessXyr1X+WKzgSzag7NjHVaO/JOdeUypOVnwDF7S985it5RdjTXUZH2tznl yovi9pyJtZx3N7fnvaKNC87Qn+1or/vaM+4HdDcnD9jPYk0w4gPTG413fsbC5xTs2W2J D8rmrE9CVpBZGs6AGzmdHO7JbmPtfnOfs33RCFEv29IsJ4A5EedLOakojy7pDzOVntTz ry1Q== X-Gm-Message-State: AOJu0YzCBODWgOxF+R0ihFfAprtCnQR+En26gxabaFS8YToZTZxDO+kb h5nWwrZfoNtMgB84LRI4jjCkaHzRjTcrrkLzh97xdQ5yLsT/eolaZa3hBPBy+hFhnO4elYI1FG2 Q7zKlRnyGiX7pDzQpH4EguzHB3qx7TylemeLb X-Google-Smtp-Source: AGHT+IFLfI+QVnBGQBrrQmHn9pIjxz6rn+Ig0eY7W4cofKy0FCCei109/RonMNR87LrdLiyaoj1zg6HqjAXh4M4gOWE= X-Received: by 2002:a05:6871:8aa:b0:215:17f1:3aa with SMTP id r42-20020a05687108aa00b0021517f103aamr370639oaq.3.1706907770631; Fri, 02 Feb 2024 13:02:50 -0800 (PST) MIME-Version: 1.0 References: <20240131175027.3287009-1-jeffxu@chromium.org> <20240131193411.opisg5yoyxkwoyil@revolver> <20240201204512.ht3e33yj77kkxi4q@revolver> <58408.1706828083@cvs.openbsd.org> <66496.1706893543@cvs.openbsd.org> In-Reply-To: <66496.1706893543@cvs.openbsd.org> From: Jeff Xu Date: Fri, 2 Feb 2024 13:02:38 -0800 Message-ID: Subject: Re: [PATCH v8 0/4] Introduce mseal To: Theo de Raadt Cc: Linus Torvalds , "Liam R. Howlett" , Jonathan Corbet , akpm@linux-foundation.org, keescook@chromium.org, jannh@google.com, sroettger@google.com, willy@infradead.org, gregkh@linuxfoundation.org, usama.anjum@collabora.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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 7A068180023 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: 863gsica9sx5p1ctsrtpgusykgjx88h8 X-HE-Tag: 1706907771-552963 X-HE-Meta: U2FsdGVkX18mZWBXPyaKEN3ne0Lo6IWvNcx0cPH25H+DiCAT7cjk2Trd5mjGBnii1iSP/OgH0RHthiRyQdMfDJE3Kis8njf3M8/0fYmCnZ5NiHE4EHpYNcd7drd6i2CGjYQdwqI9Y1PuP5jCSmbSf2Zeg/gGoB+/7Br3c3vgqamkVSSZOU5Bn1fzmd3qa7ARLPyPsT0Q7kvdzSi0OWbGLQFAbpeuuEDpEPOWjZZw5WMMNxDk4DjGn2dAUD5uRJVrb2mz43D8d0477uVNNYR+CnH8HTYQzGtCgCExsuVzaJLd4GyNnbSG/N5KSsvP+2GbSY8RZFeeg7n3IpIcKi9NEMYUZVONqhMC5/WNF/Iew4tgfR4HdJd8KG40FNVBdg8I+ijOX+nlMnKOMVbEkoEv+FMwEUJtFdVqJV96E2HciN1XlyNIanFDjjpQONgMuCM0kvphYhpxi+CmszQQAFAxWWwm1HYYBl8QGnthbU2A+xqEynjfTrmTDbR6+A0rKbZ2UPdDm4MvoD4ERq7O86sM56BzkU4zwLKLgsxoLLnJ8NUQx1SO8n2l3px7kVb4C1yTZ6mwu85TAWeLhUJfXzsPN8loeU6e72rRCKef8TATo+x+FaDtw6wM2gDei5rRydhCtLTj+Ema5+WWNlDcjCMHsmgb+1EBnCfuSouHJeNouVXR2ngPJg6YubxorwFAmbVDji3BK0PAg60Bot7clG6N3sb/ONwyLarwriRGDq8oaUGktnWctJh7HgfaSlfLr4bdCwMr2DqHAzAtY5UgRDdXT9QG+nxvKTeR3icesdxjWMVbZsPQREYA79vJ+33M8BWCfbqcEvfKlAJDE8ASsGiu6yRr0RffQEhH5SOEamhpL9yI1jErruev0wTwwFp2mKS9jdjTgGn7UEgALb7mVGEN9V1JAo4e6JjeBb+2AGqFFBrMDp110O2ZJV5cK6L4gyXTkbOPVq22ehsrWlXD80Y D4gn9TAN sp20/tKPWg/Tv97WOfwfT2YJerUNJiC0gmmPYqo+OL+///4RtyEc/nOQEtG2+7v8uo8zYL7qkd2SOOD+LDC4AtCJIWj5qN4JP4A7DXSd98PUAmXM5roVFNU1ELqTa71iRuf3lWVisssvDDbG/68UmB0+Pcs5tZT8szaA1n2A1Z70fNgu9/lbrUw6wGn7opaYT4zPdoVIzyt/bvpI90NV3KgWGvkImu58miG/mANYGmY4uMlgYVXBFAegU+hkdxj1caIyJ4fF5A/dKfcS2W9hNuu9+xVNXyyyUlXe1hPSwS92HoB/RSwiHfr3Wu1DJMeZp3IlCcK5eLY8pORbT9XGjgg0PJCjcZb9ABBMRasPhmb0rqbA= 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 Fri, Feb 2, 2024 at 9:05=E2=80=AFAM Theo de Raadt = wrote: > > Another interaction to consider is sigaltstack(). > > In OpenBSD, sigaltstack() forces MAP_STACK onto the specified > (pre-allocated) region, because on kernel-entry we require the "sp" > register to point to a MAP_STACK region (this severely damages ROP pivot > methods). Linux does not have MAP_STACK enforcement (yet), but one day > someone may try to do that work. > > This interacted poorly with mimmutable() because some applications > allocate the memory being provided poorly. I won't get into the details > unless pushed, because what we found makes me upset. Over the years, > we've upstreamed diffs to applications to resolve all the nasty > allocation patterns. I think the software ecosystem is now mostly > clean. > > I suggest someone in Linux look into whether sigaltstack() is a mseal() > bypass, perhaps somewhat similar to madvise MADV_FREE, and consider the > correct strategy. > Thanks for bringing this up. I will follow up on sigaltstack() in Linux. > This is our documented strategy: > > On OpenBSD some additional restrictions prevent dangerous address sp= ace > modifications. The proposed space at ss_sp is verified to be > contiguously mapped for read-write permissions (no execute) and inca= pable > of syscall entry (see msyscall(2)). If those conditions are met, a = page- > aligned inner region will be freshly mapped (all zero) with MAP_STAC= K > (see mmap(2)), destroying the pre-existing data in the region. Once= the > sigaltstack is disabled, the MAP_STACK attribute remains on the memo= ry, > so it is best to deallocate the memory via a method that results in > munmap(2). > > OK, I better provide the details of what people were doing. > sigaltstacks() in .data, in .bss, using malloc(), on a buffer on the > stack, we even found one creating a sigaltstack inside a buffer on a > pthread stack. We told everyone to use mmap() and munmap(), with MAP_STA= CK > if #ifdef MAP_STACK finds a definition. >