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 8B73FC433EF for ; Tue, 5 Jul 2022 19:57:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231318AbiGET5Q (ORCPT ); Tue, 5 Jul 2022 15:57:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51756 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230095AbiGET5O (ORCPT ); Tue, 5 Jul 2022 15:57:14 -0400 Received: from mail.skyhub.de (mail.skyhub.de [IPv6:2a01:4f8:190:11c2::b:1457]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 205DD12609; Tue, 5 Jul 2022 12:57:14 -0700 (PDT) Received: from zn.tnic (p200300ea970ff625329c23fffea6a903.dip0.t-ipconnect.de [IPv6:2003:ea:970f:f625:329c:23ff:fea6:a903]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 563241EC0513; Tue, 5 Jul 2022 21:57:08 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1657051028; 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:in-reply-to:in-reply-to: references:references; bh=Y0U35vMX74kXxtKME+uItAJHsSwmFddMjvSCpjyQPj8=; b=DiwfS7UbthNvF8uPkSvMWijUr+9SR1Oegvu9M94gxrifro3VGXsAzTZgbkkfR+bTkof9CU NEcWkSCBrtbKJnT/X+6bhlEH/oXTb9HMZwuAieiM/e3LdzZe/20wFDfVdGBl07ojky6143 L0dNZFDKdpgatJx+Wz78IitJ+up+C8E= Date: Tue, 5 Jul 2022 21:57:04 +0200 From: Borislav Petkov To: "Jason A. Donenfeld" Cc: linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org, x86@kernel.org, Catalin Marinas , Will Deacon , Michael Ellerman , Heiko Carstens , Alexander Gordeev , Thomas Gleixner , "H . Peter Anvin" , Greg Kroah-Hartman , Arnd Bergmann Subject: Re: [PATCH] random: remove CONFIG_ARCH_RANDOM and "nordrand" Message-ID: References: <20220705190121.293703-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-s390@vger.kernel.org On Tue, Jul 05, 2022 at 09:44:17PM +0200, Jason A. Donenfeld wrote: > Oh, huh. Maybe in that case I should adjust the message to say "consider > using `random.trust_cpu=0`," which is the thing that would actually make > a security difference. Why isn't that option documented in Documentation/admin-guide/kernel-parameters.txt? > But actually, one thing that wasn't clear to me was: does `nordrand` > affect what userspace sees? While random.c is okay in lots of > circumstances, I could imagine `nordrand` playing a role in preventing > userspace from using it, which might be desirable. Is this the case? If > so, I can remove the nordrand chunk from this patch for v2. If not, I'll > adjust the text to mention `random.trust_cpu=0`. Unfortunately, it doesn't disable the instruction. It would be lovely if we had a switch like that... That's why this message is supposed to be noisy so that people can pay attention at least. > In the sense that random.c can handle mostly any input without making > the quality worse. So, you can't accidentally taint it. The only risk is > if it thinks RDRAND is good and trustable when it isn't, but that's what > `random.trust_cpu=0` is for. And that's why I'm saying that if you detect RDRAND returning the same thing over and over again, you should simply stop using it. Automatically. Not rely on the user to do anything. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette 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 lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (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 69706C43334 for ; Tue, 5 Jul 2022 19:57:50 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4Lctkh6V3gz3c3D for ; Wed, 6 Jul 2022 05:57:48 +1000 (AEST) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=alien8.de header.i=@alien8.de header.a=rsa-sha256 header.s=dkim header.b=DiwfS7Ub; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=alien8.de (client-ip=5.9.137.197; helo=mail.skyhub.de; envelope-from=bp@alien8.de; receiver=) Authentication-Results: lists.ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=alien8.de header.i=@alien8.de header.a=rsa-sha256 header.s=dkim header.b=DiwfS7Ub; dkim-atps=neutral Received: from mail.skyhub.de (mail.skyhub.de [5.9.137.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4Lctk26Ydbz300x for ; Wed, 6 Jul 2022 05:57:14 +1000 (AEST) Received: from zn.tnic (p200300ea970ff625329c23fffea6a903.dip0.t-ipconnect.de [IPv6:2003:ea:970f:f625:329c:23ff:fea6:a903]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 563241EC0513; Tue, 5 Jul 2022 21:57:08 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1657051028; 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:in-reply-to:in-reply-to: references:references; bh=Y0U35vMX74kXxtKME+uItAJHsSwmFddMjvSCpjyQPj8=; b=DiwfS7UbthNvF8uPkSvMWijUr+9SR1Oegvu9M94gxrifro3VGXsAzTZgbkkfR+bTkof9CU NEcWkSCBrtbKJnT/X+6bhlEH/oXTb9HMZwuAieiM/e3LdzZe/20wFDfVdGBl07ojky6143 L0dNZFDKdpgatJx+Wz78IitJ+up+C8E= Date: Tue, 5 Jul 2022 21:57:04 +0200 From: Borislav Petkov To: "Jason A. Donenfeld" Subject: Re: [PATCH] random: remove CONFIG_ARCH_RANDOM and "nordrand" Message-ID: References: <20220705190121.293703-1-Jason@zx2c4.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-s390@vger.kernel.org, "H . Peter Anvin" , Arnd Bergmann , Will Deacon , Greg Kroah-Hartman , Catalin Marinas , Heiko Carstens , x86@kernel.org, linux-kernel@vger.kernel.org, Alexander Gordeev , linuxppc-dev@lists.ozlabs.org, Thomas Gleixner , linux-arm-kernel@lists.infradead.org Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Tue, Jul 05, 2022 at 09:44:17PM +0200, Jason A. Donenfeld wrote: > Oh, huh. Maybe in that case I should adjust the message to say "consider > using `random.trust_cpu=0`," which is the thing that would actually make > a security difference. Why isn't that option documented in Documentation/admin-guide/kernel-parameters.txt? > But actually, one thing that wasn't clear to me was: does `nordrand` > affect what userspace sees? While random.c is okay in lots of > circumstances, I could imagine `nordrand` playing a role in preventing > userspace from using it, which might be desirable. Is this the case? If > so, I can remove the nordrand chunk from this patch for v2. If not, I'll > adjust the text to mention `random.trust_cpu=0`. Unfortunately, it doesn't disable the instruction. It would be lovely if we had a switch like that... That's why this message is supposed to be noisy so that people can pay attention at least. > In the sense that random.c can handle mostly any input without making > the quality worse. So, you can't accidentally taint it. The only risk is > if it thinks RDRAND is good and trustable when it isn't, but that's what > `random.trust_cpu=0` is for. And that's why I'm saying that if you detect RDRAND returning the same thing over and over again, you should simply stop using it. Automatically. Not rely on the user to do anything. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette 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 70C11C43334 for ; Tue, 5 Jul 2022 19:58:39 +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=nKAPg6x4+nt1+U8jXq5S20x4FR32UY9g0baLNEDPzU4=; b=0Ju8396i15jGpU 29eM2vUrEjpg7UxS6aDgicSa2R5BQ03wYLhBttqNHrctpAc847FVRTx808mTvFF24W79Vs/ckDtqo 51bRC3Dp4GWJEXM0/L6ATrLEp1TMg0w9bf23LyWtuEEzqex3vUfTa6OFyU1Ed+dfE4A+joAt5sAuI FCndgiYRtYGKcUIZrCkixB0VMWOtTNgFA7snuvpXgfQwDfKqpLCxEUZOctrBkZXtdhMWfpYPQPXx+ twgfFpVjDSAQhfaWkbYyaxV07lHciIY58OCIVHGQs+k6OrBCIb9999TvIsH5WhQQW5w5wsyrwrfos /zX+5ktaQBEozAK/FAHg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1o8ofd-002UeO-On; Tue, 05 Jul 2022 19:57:17 +0000 Received: from mail.skyhub.de ([2a01:4f8:190:11c2::b:1457]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1o8ofa-002Ud4-5f for linux-arm-kernel@lists.infradead.org; Tue, 05 Jul 2022 19:57:15 +0000 Received: from zn.tnic (p200300ea970ff625329c23fffea6a903.dip0.t-ipconnect.de [IPv6:2003:ea:970f:f625:329c:23ff:fea6:a903]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 563241EC0513; Tue, 5 Jul 2022 21:57:08 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1657051028; 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:in-reply-to:in-reply-to: references:references; bh=Y0U35vMX74kXxtKME+uItAJHsSwmFddMjvSCpjyQPj8=; b=DiwfS7UbthNvF8uPkSvMWijUr+9SR1Oegvu9M94gxrifro3VGXsAzTZgbkkfR+bTkof9CU NEcWkSCBrtbKJnT/X+6bhlEH/oXTb9HMZwuAieiM/e3LdzZe/20wFDfVdGBl07ojky6143 L0dNZFDKdpgatJx+Wz78IitJ+up+C8E= Date: Tue, 5 Jul 2022 21:57:04 +0200 From: Borislav Petkov To: "Jason A. Donenfeld" Cc: linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org, x86@kernel.org, Catalin Marinas , Will Deacon , Michael Ellerman , Heiko Carstens , Alexander Gordeev , Thomas Gleixner , "H . Peter Anvin" , Greg Kroah-Hartman , Arnd Bergmann Subject: Re: [PATCH] random: remove CONFIG_ARCH_RANDOM and "nordrand" Message-ID: References: <20220705190121.293703-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-20220705_125714_435221_E6D2174C X-CRM114-Status: GOOD ( 17.95 ) 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 On Tue, Jul 05, 2022 at 09:44:17PM +0200, Jason A. Donenfeld wrote: > Oh, huh. Maybe in that case I should adjust the message to say "consider > using `random.trust_cpu=0`," which is the thing that would actually make > a security difference. Why isn't that option documented in Documentation/admin-guide/kernel-parameters.txt? > But actually, one thing that wasn't clear to me was: does `nordrand` > affect what userspace sees? While random.c is okay in lots of > circumstances, I could imagine `nordrand` playing a role in preventing > userspace from using it, which might be desirable. Is this the case? If > so, I can remove the nordrand chunk from this patch for v2. If not, I'll > adjust the text to mention `random.trust_cpu=0`. Unfortunately, it doesn't disable the instruction. It would be lovely if we had a switch like that... That's why this message is supposed to be noisy so that people can pay attention at least. > In the sense that random.c can handle mostly any input without making > the quality worse. So, you can't accidentally taint it. The only risk is > if it thinks RDRAND is good and trustable when it isn't, but that's what > `random.trust_cpu=0` is for. And that's why I'm saying that if you detect RDRAND returning the same thing over and over again, you should simply stop using it. Automatically. Not rely on the user to do anything. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel