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 DD442C67861 for ; Tue, 9 Apr 2024 23:37:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2BFEE6B0083; Tue, 9 Apr 2024 19:37:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 270456B0085; Tue, 9 Apr 2024 19:37:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 138056B0087; Tue, 9 Apr 2024 19:37:15 -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 EBE7A6B0083 for ; Tue, 9 Apr 2024 19:37:14 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id AAFC4A05AD for ; Tue, 9 Apr 2024 23:37:14 +0000 (UTC) X-FDA: 81991606788.23.A858AA1 Received: from mail-pl1-f174.google.com (mail-pl1-f174.google.com [209.85.214.174]) by imf05.hostedemail.com (Postfix) with ESMTP id AB279100011 for ; Tue, 9 Apr 2024 23:37:12 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=NkYACEZT; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf05.hostedemail.com: domain of keescook@chromium.org designates 209.85.214.174 as permitted sender) smtp.mailfrom=keescook@chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1712705832; 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:dkim-signature; bh=R3GBllj8XS/Lgw7EDpDRRfiZJH4dQ/8JO1yJUn0SBBo=; b=EA/w/X65gKmoz5erWtHOmh70NKmhffUjn27/ur/PoDq3lgxygJxtia6oju+GCQAol25spC IhCIfYlFipthIEtzrI4291urj0bIJrLlETnBSHiCoEC1xMcPVAyuS9Xrjxwr7tZ/hXGrH4 fzNHlXrzh67YK8jufJ+JGNsTkBRliKI= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=NkYACEZT; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf05.hostedemail.com: domain of keescook@chromium.org designates 209.85.214.174 as permitted sender) smtp.mailfrom=keescook@chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1712705832; a=rsa-sha256; cv=none; b=u3retOup3/NkY4ThpNTx8rkaBRD0qZnxthkBAGRB5X+DH0qetIQEeJxsHp5eo/VyCFTR+d oIlMK2z4cEUS/8PsaUK1AE7np8HUXY4Z2mNk9F3d+cK4ysidBRK7FOtBLAFmEHtE8rLn3o zP3jUyJH2QjDljUE0jXvO72JC9lpgvQ= Received: by mail-pl1-f174.google.com with SMTP id d9443c01a7336-1e2232e30f4so54535035ad.2 for ; Tue, 09 Apr 2024 16:37:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1712705831; x=1713310631; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=R3GBllj8XS/Lgw7EDpDRRfiZJH4dQ/8JO1yJUn0SBBo=; b=NkYACEZTMVWnRnDd1+0DAGSI5BpiVW8gDBbzVN3ZkPAllgx71u8DxP9uBvSryQJ68h cu4QHY5R0OaKq9FDYM8EsCMz0zc/Chuw+Zstli7KJk64gbrYulDVOp8zdr4Va0iZ2rF3 ARyB9So9GPZkK8dx8HH29uXuq2o00fv2CLG4k= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712705831; x=1713310631; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=R3GBllj8XS/Lgw7EDpDRRfiZJH4dQ/8JO1yJUn0SBBo=; b=IEsAC7FZNjzKdEzuWG8lxRYd0S3HJb0cd2Y5S8tKMEEcJDPGUlipw2fx4jcmoICgGQ w/2wz6sKTffQxagLn6LoRp5zdoidCJ0qj+7cmaLkY96u4yK8yKRqyYR0Q2KJSHkrZURc 51eIZTI/iS4iv/yg2g01+GjXo/k5SPSqNeqwVaZxYD7DYee3s22FYxazHJJUJHICLv9J 44pkb1RApjykMe3VrSDV9a5/3iIuAuFY77/MkzMgG5mLq1mrTqYYy5HqA6+WYUuSkJgw wJZf10y5/DuuzgSz9/q51shnuCyygDQuDiXQI87X7GMX4SuVIut6lzW7mZfXxmCXL7Ka tATg== X-Forwarded-Encrypted: i=1; AJvYcCUxqE325cdTDaZbMs3ZKm+c2AT5n6njN/Q4VIh8Bux53I3B/TaFJolV3CnJjRpCyagVf95lsFevnGvZ1wzRDMV8/mQ= X-Gm-Message-State: AOJu0Yxib2avQZu/0QckjKRF6FaNBweEQFLLZVYTgJCRXNYfaa63YHI9 5D/rzwKVkMQyf8zu/qFka7eC0OY5TZO+xTJPS3peEKQDxL4B/PFynHL3AolnzQ== X-Google-Smtp-Source: AGHT+IFGdPZEzpneRh+zF6NNUt7U7MwmMmltzsSaPxDXzFgDYjGM/3hI5oS+TZohMG0Jhx7lVLFtgw== X-Received: by 2002:a17:902:9303:b0:1e0:a3dd:82df with SMTP id bc3-20020a170902930300b001e0a3dd82dfmr1075461plb.38.1712705831382; Tue, 09 Apr 2024 16:37:11 -0700 (PDT) Received: from www.outflux.net ([198.0.35.241]) by smtp.gmail.com with ESMTPSA id kn12-20020a170903078c00b001e0c91d448fsm9479230plb.112.2024.04.09.16.37.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 09 Apr 2024 16:37:10 -0700 (PDT) Date: Tue, 9 Apr 2024 16:37:10 -0700 From: Kees Cook To: "Luck, Tony" Cc: Steven Rostedt , "linux-kernel@vger.kernel.org" , "linux-trace-kernel@vger.kernel.org" , Masami Hiramatsu , Mark Rutland , Mathieu Desnoyers , Andrew Morton , "Liam R. Howlett" , Vlastimil Babka , Lorenzo Stoakes , "linux-mm@kvack.org" , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "x86@kernel.org" , "H. Peter Anvin" , Peter Zijlstra , "Guilherme G. Piccoli" , "linux-hardening@vger.kernel.org" , Guenter Roeck , Ross Zwisler , "wklin@google.com" , Vineeth Remanan Pillai , Joel Fernandes , Suleiman Souhlal , Linus Torvalds , Catalin Marinas , Will Deacon Subject: Re: [POC][RFC][PATCH 0/2] pstore/mm/x86: Add wildcard memmap to map pstore consistently Message-ID: <202404091628.BEC1FAC8@keescook> References: <20240409210254.660888920@goodmis.org> <20240409172358.34ea19f0@gandalf.local.home> <202404091519.B7B2221@keescook> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: AB279100011 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: 9r5cimwwqrygrygj7gx418sy3f6ddsri X-HE-Tag: 1712705832-459257 X-HE-Meta: U2FsdGVkX1+OoOgPswfD7xCvqbIoqgK2XF6YG845J0CzK9L6XKOOnpIDqoFoZCJFuQ+RF5sq7GYX4ysfqmJRwIF/qyTzVJ1CM5xxsNhpky6UhhML3e2JRua2PflhV7egzHCURx8rX+16mZ6sqOBCmz80djnOIQDrxx2Y9/fthV34SG7mbtXoyImoiiDLyur+iQrCK/fyynD2T97leNEVPQcbzLAbyH1zlizmgFriQtGzv8HDreszsVILdBJyrxZsEoheD/IchIo//XAVg1W7Tq/AX1ya6VpMlFYZB8RZdBIiZxL55V1KzyZyl1Y2ByoJFdm2tpXo5XLz61sdW3S7Mciw7bqet9B04qV2FP6LiZRwjKW6XvlQqCNLJT+xVfMrYxOIcPeToIUK5GTeXo8SswzO34YZSOwN5vf4Qc7KZA631Xf0VfObAXzi+iIYUocXwRyv4pxoLWovTs9nMe5rzxGa3NDzWDr1TZsHthbxXM4xhUbnG7U3FLn84strXPD2r2MDbfbB7CyJRroI+WzGQhbqDB/77Jc7Ws6EKmh/ixa/2t1UDZ+1kGq0ud2sCnX/nAQ9UTJwZmWayggIX2lEMI8W43Bmq/c2KLC4VDf/7jMBm4nL5tkyCZNFbbZaPe6GCGUREc0A6bQopDsf8GwBv1CFzqXBqavZYWrezGLIArc9yWOChrAMW64iGNe6a/0v5gTFrIJ8YtcEUZfoU3ufM0OacIJX11ft5Bpjl/5bRwxGRQoKLy/R2eU8wbO1YL55qAKEAKKyE64XRGVEzt7PRRwLAQMXggHZM3htiS0KLpxKVISyLF6VsHp45ziNhVk+jYD2HExpc+QpXzDLpiU+7jzodtlr39j9l6Vofi4UmyPdxYvxMnSahXdLwxuh0ToO+9CtlDjTTjom1SOWe0xWsb98wfh+UQUIRplhRN9iBXtzF0i6OGxNJFyvpv93TXJsr8SCJKaLdLXNX6OSdGp TojbkS1/ QaYWUAUW373i3NFhiNUe2LLhh0EWE6udgWNarc/k1AzC+vp8UI6kZZCcdOMKAW+wv2DhbSGghWJ90lb/c8F2ivGHfzJMSB74Xiplp5yYRg2sSI63YcGnYk7Kz52ZhIqnuFsrzreoplFQ+j6kY0vjXIGU5e7f8M6y6IB0+YQK8TxWj/QIDtO5BxYHYSRgX8lfxQhA6v9yxjrp8SGQSkLvuSWkpDJSBLQAP4xtJfYSpGkQ26sqJ+vhfDAmv+HbBIYvXyVZ8jHLoGj4v7+vwKeUgjTfQSp7FtCDdvbu4vnkZbUoeVh/Uj2We7W3cUujRft6n3PG5xExd7sdmUWCgau8DN1120mwij1z5XlBkkcQZuXeRr/Z0GVsvWXgoHt+upEog8hCpRA6N54haq7aVzTC7+pNlDYUMJulMWOzb9gMyjjznTeM= 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, Apr 09, 2024 at 10:25:33PM +0000, Luck, Tony wrote: > >> I forgot to mention that this makes it trivial for any machine that doesn't > >> clear memory on soft-reboot, to enable console ramoops (to have access to > >> the last boot dmesg without needing serial). > >> > >> I tested this on a couple of my test boxes and on QEMU, and it works rather > >> well. > > > > I've long wanted a "stable for this machine and kernel" memory region > > like this for pstore. It would make testing much easier. > > Which systems does this work on? I'd assume that servers (and anything > else with ECC memory) would nuke contents while resetting ECC to clean > state. Do ECC servers wipe their RAM by default? I know that if you build with CONFIG_RESET_ATTACK_MITIGATION=y on an EFI system that supports the MemoryOverwriteRequestControl EFI variable you'll get a RAM wipe... -- Kees Cook