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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id EDB92CCA47C for ; Tue, 7 Jun 2022 10:28:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241011AbiFGK2V (ORCPT ); Tue, 7 Jun 2022 06:28:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51266 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240993AbiFGK2T (ORCPT ); Tue, 7 Jun 2022 06:28:19 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7626AB7DF7 for ; Tue, 7 Jun 2022 03:28:18 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 19368B81ED9 for ; Tue, 7 Jun 2022 10:28:17 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id F15ECC385A5; Tue, 7 Jun 2022 10:28:14 +0000 (UTC) Authentication-Results: smtp.kernel.org; dkim=pass (1024-bit key) header.d=zx2c4.com header.i=@zx2c4.com header.b="NuORGd8L" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zx2c4.com; s=20210105; t=1654597692; 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: in-reply-to:in-reply-to:references:references; bh=EFatu6W8SBbcaoaZKbQzjLqPuGtYylAXIKGYFtoTLpA=; b=NuORGd8LUwfWLNMSn60llHi61VATl0SnqQDJuJEw68mvN6UJ7SgvesMijkmSG/s634trIC JFlTzx2wJxqSBfvF+V+hxXfKbrDAcTMZpv4xLSoupQvJl5xmGo9Zyg0y0UAWuVtTBc2pzW KP/vGrfkeX3b+iRZRcKxOceq0qbIRp4= Received: by mail.zx2c4.com (ZX2C4 Mail Server) with ESMTPSA id 1e7bee8b (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO); Tue, 7 Jun 2022 10:28:12 +0000 (UTC) Date: Tue, 7 Jun 2022 12:28:08 +0200 From: "Jason A. Donenfeld" To: Ard Biesheuvel Cc: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Stephen Boyd , Catalin Marinas , Russell King , Arnd Bergmann , Phil Elwell Subject: Re: [PATCH] random: do not use jump labels before they are initialized Message-ID: References: <20220607100210.683136-1-Jason@zx2c4.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Ard, On Tue, Jun 07, 2022 at 12:13:29PM +0200, Ard Biesheuvel wrote: > Hi Jason, > > On Tue, 7 Jun 2022 at 12:04, Jason A. Donenfeld wrote: > > > > [ I would like to pursue fixing this more directly first before actually > > merging this, but I thought I'd send this to the list now anyway as a > > the "backup" plan. If I can't figure out how to make headway on the > > main plan in the next few days, it'll be easy to just do this. ] > > > > What more direct fix did you have in mind here? A non-broken version of https://lore.kernel.org/lkml/20220603121543.360283-1-Jason@zx2c4.com/ As I mentioned in https://lore.kernel.org/lkml/Yp8kQrBgE3WVqqC5@zx2c4.com/ , I would like a few days to see if there's some trivial way of not needing that on arm32. If it turns out to be easy, then I'd prefer the direct fix akin to the arm64 one. If it turns out to be not easy, then I'll merge the backup commit. > > diff --git a/drivers/char/random.c b/drivers/char/random.c > > index 4862d4d3ec49..f9a020ec08b9 100644 > > --- a/drivers/char/random.c > > +++ b/drivers/char/random.c > > @@ -650,7 +650,8 @@ static void __cold _credit_init_bits(size_t bits) > > > > if (orig < POOL_READY_BITS && new >= POOL_READY_BITS) { > > crng_reseed(); /* Sets crng_init to CRNG_READY under base_crng.lock. */ > > - execute_in_process_context(crng_set_ready, &set_ready); > > + if (static_key_initialized) > > + execute_in_process_context(crng_set_ready, &set_ready); > > Can we just drop this entirely, and rely on the hunk below to set the > static key? What justifies having two code paths that set the static > key in different ways on different architectures? No, we can't. The hunk below (A) is called from init/main.c some time after jump_label_init(). The hunk above (B) is called whenever we reach the 256-bit mark. The order is (B)(A) on machines that get seeded from efi or device tree. The order is (A)(B) on all other machines, which reach the 256-bit mark at "some point"... could be after a second, a minute, whenever enough estimated entropy has been accounted. Jason 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 8BC27C433EF for ; Tue, 7 Jun 2022 10:33:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=mybUixdhrNpeLoGw3R0xXcC5s0qCyUCIDrXS46sQTVM=; b=gBij45AJAOyB/k jl0L9GRH6eRgNduQCpIbEbIfs8aMLo4MEOETQaTkeg/65/6emWYUvBp8+kGkf6qdCjZT6LxreV15v ELgHik8NyZhy9+xlWwt7PdPOkYMbma8hf/vv8zoUC21f35FM4KDZmNULEz+RqSWw3Wk+/rwx1qFQt PSj3ioXyX6mzjHRbqEMatxW/LgQqj/XsdknY30t6So7Bu6oTnfnzauLv8UlFhxsS20PSDgLnuTpxt duVzkeXp22U8VtNqf2BIY4sahdNzu6vSLWyPhPi3/wK6wsA+dCWatxecq9hAzvpMMbvGRODwZAg9A UAL9DgJvkM9qyazHHX8g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nyWVW-006g4M-Ne; Tue, 07 Jun 2022 10:32:19 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nyWRd-006eMj-2k for linux-arm-kernel@lists.infradead.org; Tue, 07 Jun 2022 10:28:18 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 6917261319; Tue, 7 Jun 2022 10:28:16 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id F15ECC385A5; Tue, 7 Jun 2022 10:28:14 +0000 (UTC) Authentication-Results: smtp.kernel.org; dkim=pass (1024-bit key) header.d=zx2c4.com header.i=@zx2c4.com header.b="NuORGd8L" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zx2c4.com; s=20210105; t=1654597692; 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: in-reply-to:in-reply-to:references:references; bh=EFatu6W8SBbcaoaZKbQzjLqPuGtYylAXIKGYFtoTLpA=; b=NuORGd8LUwfWLNMSn60llHi61VATl0SnqQDJuJEw68mvN6UJ7SgvesMijkmSG/s634trIC JFlTzx2wJxqSBfvF+V+hxXfKbrDAcTMZpv4xLSoupQvJl5xmGo9Zyg0y0UAWuVtTBc2pzW KP/vGrfkeX3b+iRZRcKxOceq0qbIRp4= Received: by mail.zx2c4.com (ZX2C4 Mail Server) with ESMTPSA id 1e7bee8b (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO); Tue, 7 Jun 2022 10:28:12 +0000 (UTC) Date: Tue, 7 Jun 2022 12:28:08 +0200 From: "Jason A. Donenfeld" To: Ard Biesheuvel Cc: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Stephen Boyd , Catalin Marinas , Russell King , Arnd Bergmann , Phil Elwell Subject: Re: [PATCH] random: do not use jump labels before they are initialized Message-ID: References: <20220607100210.683136-1-Jason@zx2c4.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220607_032817_250291_6EA3D3FF X-CRM114-Status: GOOD ( 30.56 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Ard, On Tue, Jun 07, 2022 at 12:13:29PM +0200, Ard Biesheuvel wrote: > Hi Jason, > > On Tue, 7 Jun 2022 at 12:04, Jason A. Donenfeld wrote: > > > > [ I would like to pursue fixing this more directly first before actually > > merging this, but I thought I'd send this to the list now anyway as a > > the "backup" plan. If I can't figure out how to make headway on the > > main plan in the next few days, it'll be easy to just do this. ] > > > > What more direct fix did you have in mind here? A non-broken version of https://lore.kernel.org/lkml/20220603121543.360283-1-Jason@zx2c4.com/ As I mentioned in https://lore.kernel.org/lkml/Yp8kQrBgE3WVqqC5@zx2c4.com/ , I would like a few days to see if there's some trivial way of not needing that on arm32. If it turns out to be easy, then I'd prefer the direct fix akin to the arm64 one. If it turns out to be not easy, then I'll merge the backup commit. > > diff --git a/drivers/char/random.c b/drivers/char/random.c > > index 4862d4d3ec49..f9a020ec08b9 100644 > > --- a/drivers/char/random.c > > +++ b/drivers/char/random.c > > @@ -650,7 +650,8 @@ static void __cold _credit_init_bits(size_t bits) > > > > if (orig < POOL_READY_BITS && new >= POOL_READY_BITS) { > > crng_reseed(); /* Sets crng_init to CRNG_READY under base_crng.lock. */ > > - execute_in_process_context(crng_set_ready, &set_ready); > > + if (static_key_initialized) > > + execute_in_process_context(crng_set_ready, &set_ready); > > Can we just drop this entirely, and rely on the hunk below to set the > static key? What justifies having two code paths that set the static > key in different ways on different architectures? No, we can't. The hunk below (A) is called from init/main.c some time after jump_label_init(). The hunk above (B) is called whenever we reach the 256-bit mark. The order is (B)(A) on machines that get seeded from efi or device tree. The order is (A)(B) on all other machines, which reach the 256-bit mark at "some point"... could be after a second, a minute, whenever enough estimated entropy has been accounted. Jason _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel