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 4082FC5479D for ; Mon, 9 Jan 2023 10:34:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BB9418E0003; Mon, 9 Jan 2023 05:34:19 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B69BF8E0001; Mon, 9 Jan 2023 05:34:19 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A0AA38E0003; Mon, 9 Jan 2023 05:34:19 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 8DF468E0001 for ; Mon, 9 Jan 2023 05:34:19 -0500 (EST) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 56E781C5D4C for ; Mon, 9 Jan 2023 10:34:19 +0000 (UTC) X-FDA: 80334901038.10.28757AB Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf04.hostedemail.com (Postfix) with ESMTP id B70F340016 for ; Mon, 9 Jan 2023 10:34:16 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=MtNexugY; spf=pass (imf04.hostedemail.com: domain of fweimer@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=fweimer@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1673260457; 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=Gp01bbHImBb9jQ++aTa7ksC+hJELx0J0kuwwfn5XG7k=; b=zH5HQ6wH69/xO9C5aPxv75EbcdK5Z/YJsFwqdDwfhsLjpNVp0x5N2xKqMxops1Akv2awlg jjQ5Vrp956aJZ5HzQieupLytDYtzGzCf7rDm+yKcjPdWKs6K6aTeRkbJe6rVBJupayt1mH z5fVAXyzCZyp2rrZvAE1RHE4YKwallg= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=MtNexugY; spf=pass (imf04.hostedemail.com: domain of fweimer@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=fweimer@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1673260457; a=rsa-sha256; cv=none; b=jXFL6SU6vjjFcqa4Xr4xPO9CrzthwbE05EO/qFUaizL+IgqkKkDz/V7jTGNYwa9KnankbS ffoSQx1ggqRniDiBi8sibJcV8+Ys+fB3Y0deZdlEeuzfD4UyQMTapJqeBy4iQ9/jlLla3G inJdvIkB82tLEbOsU3+gwby28J8zbSE= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1673260455; h=from:from: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; bh=Gp01bbHImBb9jQ++aTa7ksC+hJELx0J0kuwwfn5XG7k=; b=MtNexugY3pxrxrVam2SJH0kjTFQ56Iw3TL89fzIsgdNrx4oKxbY8AtPwoUtuXNUWvRdSAm SKeQcnVcn2X2J5e89DMKm/IbfllRkUzSMt1uezuF0phtgmLrp6hVFkBp8ZGOs1pv1RefvF XRgB9kcwIcbsg5uADo4k6GEwhyrAKLM= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-192-6lJLLzdVMhu3P5ythx0hnw-1; Mon, 09 Jan 2023 05:34:14 -0500 X-MC-Unique: 6lJLLzdVMhu3P5ythx0hnw-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id E9F9E1C09044; Mon, 9 Jan 2023 10:34:13 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.2.16.32]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 08EA240C2064; Mon, 9 Jan 2023 10:34:10 +0000 (UTC) From: Florian Weimer To: Linus Torvalds Cc: "Jason A. Donenfeld" , Andy Lutomirski , Ingo Molnar , linux-kernel@vger.kernel.org, patches@lists.linux.dev, tglx@linutronix.de, linux-crypto@vger.kernel.org, linux-api@vger.kernel.org, x86@kernel.org, Greg Kroah-Hartman , Adhemerval Zanella Netto , "Carlos O'Donell" , Arnd Bergmann , Jann Horn , Christian Brauner , linux-mm@kvack.org, mlichvar@redhat.com Subject: Re: [PATCH v14 2/7] mm: add VM_DROPPABLE for designating always lazily freeable mappings References: <20230101162910.710293-1-Jason@zx2c4.com> <20230101162910.710293-3-Jason@zx2c4.com> Date: Mon, 09 Jan 2023 11:34:09 +0100 In-Reply-To: (Linus Torvalds's message of "Tue, 3 Jan 2023 11:54:35 -0800") Message-ID: <874jt0kndq.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.1 on 10.11.54.1 X-Stat-Signature: iekaeyqzqrjwciwp7ji349wwa8t1q19g X-Rspam-User: X-Rspamd-Queue-Id: B70F340016 X-Rspamd-Server: rspam06 X-HE-Tag: 1673260456-306259 X-HE-Meta: U2FsdGVkX19dHzxkiPLxR4O/qH8GGwesviNcBAItzzAmPSYRj457xHamm29y3RLLq6wNKQeE8zG5vw7885AAwtqO1yKnnFyIOb7td/JLHhMkX5shAZxBKrGInoVY6IV/SXPdLduiVrZP54LLVW4ICDppAcMGhg4cyH7oXCi0Kr04vP5y9/a/mUdscZuDffRuJmdLMlrntk3Rs48SmVTYbYunOZhdFMzAS7kx5qQ+9jrw5n3sskKx+wQOTDmkaJa7CeYD6NL3Ok4MKtcH1z7bNQJ7FWTwOZ76fzS0PmqT8qqh0hZXvFz8BUGLNGKqXP3VfQWy7qpTQkkLVo3kBGsX0VSt0uQpCCcO1fdxVs6qdZxlq7XMDdsfAt7NTjv37DNfDDivFCrkQCsnzjErBK9v7BEmZQ+uhkgAR+oUDynBoCZ58GMyrqsnXhKUvs+KuoqXefqjBYvVY3WxNFr2MGcaaPcIMsTdvaVSYumKx/fdA6ahqKmo2sIt+PNfksfGM8Vb2N8+XdYIUp4sRHMYTdoTVgyRaLwpC6X82ubee6kb5l6ujvqaYqgfqqPfn5fZ8D6LOf+r8C+ExxPCT4IEB1mxs76hx8LQMoSuSGaRGHtppgHe1jRr3eLftc438EY68GBOGI3MoHkrkz36kR/JkPna15qgivh0+yaCugHGbxXHG44wjYnqZSO3Bl+rIno1QFjb+82v1bm7PCxKsDiIefFqccV4gL89pxAO4AVcTy7KCGFLAJX3cOStmMOSsvTlBV7eiGty2n75nOvOgtLVgqepvMOUMCJc52i33NiIW0VV+FuuinRmAHCR6/5akSzXdxeueOuKcYS/QxeAmi+/867jfsjl+RoUBfq9JafvdimRu1Yznw6WofkIeAlkVeKyGp7tRzBoRxB4EaOQyENsQHlnDIEwGrdhgUPd4daopACcX2TYSdwH7d8fdA== 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: * Linus Torvalds: > On Tue, Jan 3, 2023 at 11:35 AM Jason A. Donenfeld wrot= e: >> >> I don't think this is about micro-optimization. Rather, userspace RNGs >> aren't really possible in a safe way at the moment. > > "Bah, humbug", to quote a modern-time philosopher. > > It's humbug simply because it makes two assumptions that aren't even vali= d: > > (a) that you have to do it in user space in the first place > > (b) that you care about the particular semantics that you are looking for > > The thing is, you can just do getrandom(). It's what people already > do. Problem solved. We are currently doing this in glibc for our arc4random implementation, after Jason opposed userspace buffering. If chrony is recompiled against the glibc version of arc4random (instead of its OpenBSD compat version, which uses userspace buffering), the result is a 25% drop in NTP packet response rate: | The new arc4random using getrandom() seems to have a significant | impact on performance of chronyd operating as an NTP server. On an | Intel E3-1220 CPU, I see that the maximum number of requests per | second dropped by about 25%. That would be an issue for some public | NTP servers. arc4random is too slow This is *not* =E2=80=9Carc4random is 25% slower=E2=80=9D, it is the measure= d overall impact on server performance. Historically, the solution space for getrandom and arc4random are slightly different. The backronym is =E2=80=9CA Replacement Call For rando= m=E2=80=9D, i.e., you should be able to use arc4random without worrying about performance. I don't expect cryptographic libraries to turn to arc4random to implement their random number generators, and that programmers that use low-level OpenSSL primitives (for example) keep calling RAND_bytes instead of arc4random because it is available to them. We did these changes on the glibc side because Jason sounded very confident that he's able to deliver vDSO acceleration for getrandom. If that fails to materialize, we'll just have to add back userspace buffering in glibc. At least we can get process fork protection via MADV_WIPEONFORK, solving a real problem with the usual arc4random compat implementation. (The OpenBSD mechanism for this is slightly different.) We won't get VM fork protection or forward secrecy against ptrace. But the latter is rather speculative anyway because if you can do ptrace once, you can likely do ptrace twice, the first time patching the process to remove forward secrecy. There is a real gap for VM forks, but I'm not sure how much that matters in practice. Live migration has to be implemented in such a way that this isn't observable (otherwise TCP connections etc. would break), and long-term keys probably shouldn't be generated under virtualization anyway. Thanks, Florian