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 7DD1DCFB45C for ; Tue, 8 Oct 2024 15:01:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E2C126B0092; Tue, 8 Oct 2024 11:01:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DDBA76B0093; Tue, 8 Oct 2024 11:01:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CCA976B0095; Tue, 8 Oct 2024 11:01:06 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id AD01E6B0092 for ; Tue, 8 Oct 2024 11:01:06 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 62EE0AB623 for ; Tue, 8 Oct 2024 15:01:03 +0000 (UTC) X-FDA: 82650747732.20.A11243C Received: from mail-oo1-f48.google.com (mail-oo1-f48.google.com [209.85.161.48]) by imf07.hostedemail.com (Postfix) with ESMTP id 35D0E4002F for ; Tue, 8 Oct 2024 15:01:02 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=FedB3EXB; spf=pass (imf07.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.161.48 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=1728399620; 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=vNaoqE9iLYEqaxmKhH8Fh/36izXlvroo3qs4o9RMtlo=; b=XJtUB5gZR2Tzuw2YoypTB8iA9UPB8wQgrZIe++mAemek2s/7wpkVJyWMJLMBCjmieI5wl1 tcNYG5SWHld12BeX1x1OByGWK0ijsBmoX860IXCMsyg8CQ+Zp/8XUaCOKPwpcEfrAIYuov rhBDJj6UFHMksfEY8n+CcDR9tiQqHbo= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=FedB3EXB; spf=pass (imf07.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.161.48 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=1728399620; a=rsa-sha256; cv=none; b=bBmVj7217k33ZFTWXqH9fxbf1eLoCQN00GtS1SF3WsaiI7AzjvBkcPslpAulLYWcuii0Rg ZY2uFq+Jo8o/8qwQosmD4Y1wKka73ZMwzJ/nMLdtL9dl5Y8ree3SeP4pKFdgz+UEcKCxyU jd7SaEAfQsG4olQ/AoeiA2ZqQGvjQKA= Received: by mail-oo1-f48.google.com with SMTP id 006d021491bc7-5e1c8357b23so238947eaf.1 for ; Tue, 08 Oct 2024 08:01:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1728399662; x=1729004462; 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=vNaoqE9iLYEqaxmKhH8Fh/36izXlvroo3qs4o9RMtlo=; b=FedB3EXB2AMdkyB2eFxOXjneoqa5FpiL9XuLer5exyvDBXosjp8aC0Np31WS2so7IQ aUZ7w9quOCXCt+7uBfQaJfuC5HMWXbGg6Hh6DNKpOJzb42E72PtbnEdhSYS4NNlIupUi +zQeAPBtezo202XW783pJfhd6ic9aw2pc+oF8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728399662; x=1729004462; 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=vNaoqE9iLYEqaxmKhH8Fh/36izXlvroo3qs4o9RMtlo=; b=QZ82HPYyIMYETd25tRmy0f8QCFRZfoviK8hzxFt+nhNT1MulrL7T6tsXYzjHNSL5N6 LN/RelDTKh2p2h7aQxLJwkz9A09Nu0iAmh4EI1YmgLVPZGJo/tyGlGDhcW33a8KUav3d du2k9G7mCv0VYAFYN+jx/05UxCkZCHrh5TSU4otCNPsgQCLcyQ7g5Jig7fvfqQIFQjle 5nrti41NZsNgty9icK+CnVTnKRznQN95f0E7injVFqjma21Ty0TzM9lCoapd51Xk0tHh qvreSaM5VowxilyT0EJwjVfI/yxwRDG6MdOkMUvPUdDfyDC/2yMKfYWvakhy0EkVF6RS O0zg== X-Forwarded-Encrypted: i=1; AJvYcCVboEO6/fJeB8dOvebcJujc15mvk7EDe6wll2pYlaLoaiGQqF3rqHOd/rr8eZ+kcIyj/BvTs8H9jw==@kvack.org X-Gm-Message-State: AOJu0Yx7BXaGZ1LRVJyFjBy+2ffJmRw+QRYbjU87OrM0FwEtghNBFBNG exsmLnK/9yoHDtUioWFP53817rWYlWSlygQrfiU02guCaD52Ha137rX9R7py+v0+LdshvgXDCZJ LHwzan4OI/LH6zqrGN0z9nl2WIRy6qS2c9/xp X-Google-Smtp-Source: AGHT+IFMtDvnSOLpJ2+MdayuHbe1zXaSJRKropnN+uC9XI1mdmCdWI7HRfFEHmxrAvMu2kyjkRI7+J9N6QbI9kV3qvE= X-Received: by 2002:a05:6870:b30f:b0:27b:9f8b:277d with SMTP id 586e51a60fabf-287c225aee7mr2608151fac.12.1728399661695; Tue, 08 Oct 2024 08:01:01 -0700 (PDT) MIME-Version: 1.0 References: <20241004163155.3493183-1-jeffxu@google.com> In-Reply-To: From: Jeff Xu Date: Tue, 8 Oct 2024 08:00:00 -0700 Message-ID: Subject: Re: [RFC PATCH v1 0/1] seal system mappings To: "Liam R. Howlett" , jeffxu@chromium.org, akpm@linux-foundation.org, keescook@chromium.org, jannh@google.com, torvalds@linux-foundation.org, adhemerval.zanella@linaro.org, oleg@redhat.com, linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org, linux-mm@kvack.org, jorgelo@chromium.org, sroettger@google.com, ojeda@kernel.org, adobriyan@gmail.com, anna-maria@linutronix.de, mark.rutland@arm.com, linus.walleij@linaro.org, mike.kravetz@oracle.com, Jason@zx2c4.com, deller@gmx.de, rdunlap@infradead.org, davem@davemloft.net, hch@lst.de, peterx@redhat.com, hca@linux.ibm.com, f.fainelli@gmail.com, gerg@kernel.org, dave.hansen@linux.intel.com, mingo@kernel.org, ardb@kernel.org, nathan_lynch@mentor.com, dsafonov@virtuozzo.com, mhocko@suse.com, 42.hyeyoo@gmail.com, peterz@infradead.org, ardb@google.com, enh@google.com, rientjes@google.com, groeck@chromium.org, lorenzo.stoakes@oracle.com, Jeff Xu Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Stat-Signature: nqg7mrf9swdz7o84xa197qghjcqsrmen X-Rspamd-Queue-Id: 35D0E4002F X-Rspamd-Server: rspam11 X-HE-Tag: 1728399662-596183 X-HE-Meta: U2FsdGVkX18bWa/lYVeT781CVz0cKKNXNF1EdgYjbDYiD7CWSObGPYcN6OaMG1V/oHPsziJuX3s8LEtNKUVRlzduykJ7pvmFd4J87aDS/4yMoJzqNs6CdzAi/QEg4/LMEB1BfaPtqNejC2DICSABNgrJP6vxhWnfc/pk5azXgXgQ4IrL9h5wVrNPfgLQDgSp3+j20xMIqJaknysy5XahbLaMMG6JZBVw52ezjpCVtOpQD4eAKtVqwuzu2MMUKA9v50oFv5cRYu90/UcFhWmG4En0vJ5pVHxNDr2YCvIROlVOvfnmJEeGI3k+0RRNPYG2r9ZhbYYF2BkkeA89EvqzGLAIz6VZ3WQFijHPuv6oizbZ6eznnhyc0GW2ISZ27dVI58DIm7Yda4J7O1D/h5hhGPIKFvjrQY9Arjo7pVxcjPKtsz32z33ng5CvQgeWoWEtydLpUCjd125BELhFNgAVlXSVYlI4BpSpWL3MJv8k3euMvzfKyM/V3xZTolJBduJ0PyrMibYp4JDw9lzt714qhC3DNOg71njaAZbj6M1s9pPY6heOjSeetcWuCctNo/snvWkug0ZRq484GkM+LbxO7uTIAAzKnd8e/DQ7wgj4MBXUC8RPWLI1km579iS6oeVJZMfTsE0WekiMNnKMp8P4UEalDxKllIiGcRu3inMGG/xVgAMZa7fOf1cmCvJ4BDPcmSUH5WiCChVXbkHHf/LeXmC60ykEIt7rg2nm8dRNJc/rFA36qZaz871iAyB59xvZTy8PUSu2YqsbSzuqRMw5GWEHDw9ra8WMd0TOSZ2N3niMirjpVCtjtqHaGrW+UTgLEScOyFaoVuwVFVwXkWKfC1NjqKGWN15HEajmaSYKgWQ0ycFqE8JmJobehqSTCyo5mCIwRZ+NtrzNbXOZquvK7bSVD+FuecY4JAXNzNSpdlQ0vYj1CIGKI5V3wzTB3E2fMQSWK6k6aZ9hJm3us5p 9FjkCqLo me1bsWp4VMcBuTZB8hnap+wnwxbh4d/RzyPT1io6tl2T8cdsaxW0CiRPIQDNCCVLD0kccXJq0zWZ3J4ffraULuD3Sb8Wfl54LroKEEGpGZ60fpbgl5JE+i5zuEKOW+sRTjh0cd0jtMWe8g4JaBg0jLJc3NaRwppbGBS5Kl0usUa/peFero+W2JW+D1dAeHSh7oWeTr+fwAOb/eDKMkLW1GIeamG+ZGW81/kMywUqqoLBg8tZ+L/U81anPebivLP/IJKnTqZCjTKth1udrGUelydILyvdZn7AdL7PyKY+d0mHoEFbNI1E/8wQCEqG8ylSDpQrphmaCDv2KwNfz1qfasmmDvs0JJsrHP9Tlz+Cci60KVAA44ys1OD4U6CqqW2N3xSC44zcWkp9StYQ= 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 Liam, On Mon, Oct 7, 2024 at 7:19=E2=80=AFPM Liam R. Howlett wrote: > > * jeffxu@chromium.org [241004 12:32]: > > From: Jeff Xu > > > > Seal vdso, vvar, sigpage, uprobes and vsyscall. > > > > Those mappings are readonly or executable only, sealing can protect > > them from ever changing during the life time of the process. > > > > System mappings such as vdso, vvar, and sigpage (for arm) are > > generated by the kernel during program initialization. These mappings > > are designated as non-writable, and sealing them will prevent them > > from ever becoming writeable. > > But it also means they cannot be unmapped, right? > > I'm not saying it's a thing people should, but recent conversations > with the ppc people seem to indicate that people do 'things' to the vdso > such as removing it. > > Won't this change mean they cannot do that, at least if mseal is enabled > on ppc64? In which case we would have a different special mapping for > powerpc, or any other platform that wants to be able to unmap the vdso > (or vvar or whatever else?) > > In fact, I came across people removing the vdso to catch callers to > those functions which they didn't want to allow. In this case enabling > the security of mseal would not allow them to stop applications from > vdso calls. Again, I'm not saying this is a good (or bad) idea but it > happening. > > > > > Unlike the aforementioned mappings, the uprobe mapping is not > > established during program startup. However, its lifetime is the same > > as the process's lifetime [1], thus sealable. > > > > The vdso, vvar, sigpage, and uprobe mappings all invoke the > > _install_special_mapping() function. As no other mappings utilize this > > function, it is logical to incorporate sealing logic within > > _install_special_mapping(). This approach avoids the necessity of > > modifying code across various architecture-specific implementations. > > > > The vsyscall mapping, which has its own initialization function, is > > sealed in the XONLY case, it seems to be the most common and secure > > case of using vsyscall. > > > > It is important to note that the CHECKPOINT_RESTORE feature (CRIU) may > > alter the mapping of vdso, vvar, and sigpage during restore > > operations. Consequently, this feature cannot be universally enabled > > across all systems. To address this, a kernel configuration option has > > been introduced to enable or disable this functionality. I tested > > CONFIG_SEAL_SYSTEM_MAPPINGS_ALWAYS with ChromeOS, which doesn=E2=80=99t= use > > CHECKPOINT_RESTORE, to verify the sealing works. > > I am hesitant to say that CRIU is the only user of moving the vdso, as > the ppc people wanted the ability for the fallback methods to still > function when the vdso was unmapped. > > I am not sure we can change the user expected behaviour based on a > configuration option; users may be able to mmap/munmap but may not be > able to boot their own kernel, but maybe it's okay? > The text doesn't say CRIU is the **only** feature that is not compatible with this. The default config is "CONFIG_SEAL_SYSTEM_MAPPINGS_NEVER", and distribution needs to opt-in for this feature, such as ChromeOS or Android or other safe-by-default systems that doesn't allow to unmap or remap vdso in production build. Thanks -Jeff > > > > [1] https://lore.kernel.org/all/CABi2SkU9BRUnqf70-nksuMCQ+yyiWjo3fM4XkR= kL-NrCZxYAyg@mail.gmail.com/ > > > > Jeff Xu (1): > > exec: seal system mappings > > > > .../admin-guide/kernel-parameters.txt | 9 ++++ > > arch/x86/entry/vsyscall/vsyscall_64.c | 9 +++- > > fs/exec.c | 53 +++++++++++++++++++ > > include/linux/fs.h | 1 + > > mm/mmap.c | 1 + > > security/Kconfig | 26 +++++++++ > > 6 files changed, 97 insertions(+), 2 deletions(-) > > > > -- > > 2.47.0.rc0.187.ge670bccf7e-goog > >