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 52231C25B75 for ; Wed, 15 May 2024 20:19:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C4AF06B0110; Wed, 15 May 2024 16:19:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BFAD66B03BB; Wed, 15 May 2024 16:19:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A9DF36B03BC; Wed, 15 May 2024 16:19:15 -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 8AED76B0110 for ; Wed, 15 May 2024 16:19:15 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 0C703402E2 for ; Wed, 15 May 2024 20:19:15 +0000 (UTC) X-FDA: 82121744670.12.4FAB7F8 Received: from mail.alien8.de (mail.alien8.de [65.109.113.108]) by imf01.hostedemail.com (Postfix) with ESMTP id D922E40005 for ; Wed, 15 May 2024 20:19:12 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=alien8.de header.s=alien8 header.b=Az+1uV24; spf=pass (imf01.hostedemail.com: domain of bp@alien8.de designates 65.109.113.108 as permitted sender) smtp.mailfrom=bp@alien8.de; dmarc=pass (policy=none) header.from=alien8.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1715804353; 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=I+TM5XxPjG4Qj70u6A2s8F0ZAG2e+3pm2+5E6j0Lpho=; b=S2E2hR7Vmyk+JlAtrhhdv+R3VT7vaMFngZOzbL6tZlEJlLWx4nP48CRFsFZd8MrFaACJuo kF9QHizMDN3wicQh6cFBAJKX/U15IVdjDMRvxjvr2hZrIf3OJoslDhLpj/lKHNIM8uMJB2 BKpmPUcxhF31MEKuwHJHHK9NDy16IRI= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1715804353; a=rsa-sha256; cv=none; b=o2dkGm1865wTc845cMCzYcyi0S5as1630Yu9tt95NJLvURMeh75zlpvlxKecxiH4ZXzQrf 62XqSRoztbXE/GzChZXB6I4BNLO/LyJLai4JNypA4Urv1X22BewYr1o5bcbO9/uTEBDAYe I+uX8w0W17D1MEDSUuKlteJf7YWF99s= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=alien8.de header.s=alien8 header.b=Az+1uV24; spf=pass (imf01.hostedemail.com: domain of bp@alien8.de designates 65.109.113.108 as permitted sender) smtp.mailfrom=bp@alien8.de; dmarc=pass (policy=none) header.from=alien8.de Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTP id 5877940E01F6; Wed, 15 May 2024 20:19:10 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at mail.alien8.de Received: from mail.alien8.de ([127.0.0.1]) by localhost (mail.alien8.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Zw2uAITgrclB; Wed, 15 May 2024 20:19:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=alien8; t=1715804346; bh=I+TM5XxPjG4Qj70u6A2s8F0ZAG2e+3pm2+5E6j0Lpho=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Az+1uV24MRhctKN9lhn5WrN0m6bLZJW5T1B5QK7KdnCkfR8tiY0xvI9TI3J+7QMA2 Jc7aZ7V7U5MYr8ZSqAVux5K8Gwyru9TGzP80Estj5jxpPr82TnMdJlJohr5wjMcW14 NNGJM59tyMkXpgMyHI2JL5vCleOogoChGPxNx+14IVz2JI5L5FwCTKxLDVC9T8pPic DTh+3HvaDA6N5J5X2UYtv7JCmvPce0lBy+aBjUcdck8TbyW8jpLsbJRMwQiua6jWMq 6D9QJalBAQNftXhOXdt+d3tWXSzMxE4e6LFHzD9Y3XwTmQS5Aent2y9vLnifF/MQWf Z3L5OrHhoJtODBs7P9Q+UrBA4f4LADIOlXN6VnB8Y0GqFPnznDp4yZN07b2CR9gNK7 cfjtqhCOYBbJEfTJt3PLQJCehLdHKI6T3W+25Td/Mi6QWwt2lBbz3y4YJrv4VEcmY+ AhMaTvuSlCLocYJMCRSk6XeFJWioa81qeUuZrTQ0eztjVMYoMV4CX53dt7U0PjySDC EXEq0t8oh4oNPOzt4xXusfuOn9lF8ILJQeWUHiNvO/XvNgwKAsVelSBopUMx20Rxqg JfTuMNeGc8g/iZr5sDQGXgXALNOxkFMdRBlpYdyYPtkW2LfId/nM8T1YT5ICdhuaTp AIvm4Gkabd1B7ukayuBdD2NQ= Received: from zn.tnic (p5de8ee85.dip0.t-ipconnect.de [93.232.238.133]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id BB1C540E016A; Wed, 15 May 2024 20:18:37 +0000 (UTC) Date: Wed, 15 May 2024 22:18:31 +0200 From: Borislav Petkov To: Axel Rasmussen Cc: Oscar Salvador , Andrew Morton , Andy Lutomirski , "Aneesh Kumar K.V" , Christophe Leroy , Dave Hansen , David Hildenbrand , "H. Peter Anvin" , Helge Deller , Ingo Molnar , "James E.J. Bottomley" , John Hubbard , Liu Shixin , "Matthew Wilcox (Oracle)" , Michael Ellerman , Muchun Song , "Naveen N. Rao" , Nicholas Piggin , Peter Xu , Peter Zijlstra , Suren Baghdasaryan , Thomas Gleixner , linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, x86@kernel.org Subject: Re: [PATCH v2 1/1] arch/fault: don't print logs for pte marker poison errors Message-ID: <20240515201831.GDZkUYlybfejSh79ix@fat_crate.local> References: <20240510182926.763131-1-axelrasmussen@google.com> <20240510182926.763131-2-axelrasmussen@google.com> <20240515104142.GBZkSRZsa3cxJ3DKVy@fat_crate.local> <20240515183222.GCZkT_tvEffgYtah4T@fat_crate.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: D922E40005 X-Rspam-User: X-Stat-Signature: 71garskofn8hybnio1869df57i1ye8jy X-HE-Tag: 1715804352-547354 X-HE-Meta: U2FsdGVkX1/GuXIcKVpbAGGTfFF/+jlX60zLjc1/9dKuDNAT5+7t4GQ2xQ8EJnr1qTiTFlIFpGX+iNqD1HpE/JCgou2iY/Zw/qpCkIQkWf207zKeL+aP2sizKRkwWUYsGw8iddAKYDZV3hhfI86+NWmI7PkX0aKq8IqTK7IEPW+UTIJ3/wFqcDSchMrAwWBtrFwfFINBKFdc3Ke2vnmo7Q0/6JaUEpPNn73BCoky3XdV07FdCZLm8409JMfwk91iVK4kUzvPaJ/f4BGhAoOg6clQ3bk1wspy1U3TtZJzmQ9woQ23ZvF4hSkW/G4CreHQQdTlt26hnZ2IopqrTg3OOdsggI/4I4eFyBodzSvOUD/jEJxMugGWX/nZTjot1SacW/gcINT6Ph2X1kNOf0gGhyo5P+AmQoT06r2IA2YW0R7kYJLEjtAKxqGgSdUXGCTraIKWUmtBjkdcQLmJWf5lwbDmZg4tmgH57A+cyqbtMc8/WxVB5DcBvSQPp2eGv4ZM1k9G09Cnj4GY73qWr7kTENPygxBJ0aiAnYP5LNHDMbByKk6vd81+0XlIUaQdGmqU8kFGcI2ZsXoTFgFsjIbqYwd6iBw4/N4VnctUZYtlypAw8ktzlxjTud02WGkJMFBRB2T8yTY1oYlCxrmysRN64My7eDYkI17UJmf3oO/4Rx87Ycr0R84b5aVDz2LTXF5JtreMiy+JpCUxvSCqJe3Fl67Fuuq7mPUN/9s4STNDpK2XiSo7/273EE4JFu4VKqhLVUD1GuJMayKjmA+qBtboTMVezEEqcwycRBII1Oh6ywu/Rh0WBs7cFCHhune8zQOIdu+HD/qc5vGhA5Mm4kWMApugUNn7U0tA4LgMkc2LF/jnJHb47etoSKo1yUqoAH/bP0uotYIp+cJoQrwgHOkozqrbAcNyic+782DosAqrQ0xIoRff6pakS6/MdUVUqgbUEfxdSGMXXiz1nFUfP8f pKTvXXJv v4Nolj2la2I4dVE32gRsn2ipcmnsMgr6CSIHOT1qKYqMLlHXN+ubtfvSIAN0RxPDDMS9kiBosIpzg4vKn5Ao9kis7Ituwzp5OXImcOn0dVcYaLrn050kCiWOiQvbiyGWpzHNyJrqFY6RXy7UlapG4Ui5s5bpgHpKoCU05wH6AcUFhGhAx9R86AEO0Yoia8TwA7XQeXkIuoUa2LxU= 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 Wed, May 15, 2024 at 12:19:16PM -0700, Axel Rasmussen wrote: > An unprivileged process can allocate a VMA, use the userfaultfd API to > install one of these PTE markers, and then register a no-op SIGBUS > handler. Now it can access that address in a tight loop, Maybe the userfaultfd should not allow this, I dunno. You made me look at this thing and to me it all sounds weird. One thread does page fault handling for the other and that helps with live migration somehow. OMG, whaaat? Maybe I don't understand it and probably never will... But, for example, membarrier used do to a stupid thing of allowing one thread to hammer another with an IPI storm. Bad bad idea. So it got fixed. All I'm saying is, if unprivileged processes can do crap, they should be prevented from doing crap. Like ratelimiting the pagefaults or whatnot. One of the recovery action strategies from memory poison is, well, you kill the process. If you can detect the hammering process which installed that page marker, you kill it. Problem solved. But again, this userfaultfd thing sounds really weird so I could very well be way wrong. > Even in a non-contrived / non-malicious case, use of this API could > have similar effects. If nothing else, the log message can be > confusing to administrators: they state that an MCE occurred, whereas > with the simulated poison API, this is not the case; it isn't a "real" > MCE / hardware error. Yeah, I read that part in Documentation/admin-guide/mm/userfaultfd.rst Simulated poison huh? Another WTF. > In the KVM use case, the host can't just allocate a new page, because > it doesn't know what the guest might have had stored there. Best we Ok, let's think of real hw poison. When doing the recovery, you don't care what's stored there because as far as the hardware is concerned, if you consume that poison the *whole* machine might go down. So you lose the page. Plain and simple. And the guest can go visit the bureau of complaints and grievances. Still better than killing the guest or even the whole host with other guests running on it. > can do is propagate the poison into the guest, and let the guest OS > deal with it as it sees fit, and mark the page poisoned on the host. You mark the page as poison on the host and you yank it from under the guest. That physical frame is gone and the faster all the actors involved understand that, the better. > I don't disagree the guest *shouldn't* reaccess it in this case. :) > But if it did, it should get another poison event just as you say. Yes, it shouldn't. Look at memory_failure(). This will kill whole processes if it has to, depending on what the page is used for. > And, live migration between physical hosts should be transparent to > the guest. So if the guest gets a poison, and then we live migrate it, So if I were to design this, I'd do it this way: 0. guest gets hw poison injected 1. it runs memory_failure() and it kills the processes using the page. 2. page is marked poisoned on the host so no other guest gets it. That's it. No second accesses whatsoever. At least this is how it works on baremetal. This hw poisoning emulation is just silly and unnecessary. But again, I probably am missing some aspects. It all just sounded really weird to me that's why I thought I should ask what's behind all that. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette