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 7FDEBC433EF for ; Wed, 6 Jul 2022 14:55:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231690AbiGFOz7 (ORCPT ); Wed, 6 Jul 2022 10:55:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43396 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230146AbiGFOz6 (ORCPT ); Wed, 6 Jul 2022 10:55:58 -0400 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A05CAD58; Wed, 6 Jul 2022 07:55:57 -0700 (PDT) Received: from cwcc.thunk.org (pool-173-48-118-63.bstnma.fios.verizon.net [173.48.118.63]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 266Et4Za026327 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 6 Jul 2022 10:55:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing; t=1657119313; bh=ifFZJvbfIGVslUHWRDtftSqDp9BgS1ySpd5as638KpQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=jicRkedUge0cSrNp9dsPHkw4QFRERSGTRFWvzKMGECE7ezizOgSv9HxyR9V4F8S7F B3Z4cvkvhwTV+vUCLQyyRapiOOXIrh6qq6H06KmAU7CGQ4aXhLrDnNGj3ClQF1Na0r MfGlG/hzw6ibcSaN/qBTJnkql+Zzo+d40NlqpzyzX5ybtU1W3uQ2ySVzntVa7l0jYs tkDnbU64G7GfM2KZH9XpIvp8dnasZ7d1RvfrjUt2khPyFMDRUSqvqcK3+Ex61hsi7X BhyDG4ghY/zpMytxNISsWRBgmgGJllOR34RpeYEAVqRhNsCrgwz8QoCs3CgyKgd2Qk zZPwW6kHfDl3A== Received: by cwcc.thunk.org (Postfix, from userid 15806) id 75A9215C3E94; Wed, 6 Jul 2022 10:55:04 -0400 (EDT) Date: Wed, 6 Jul 2022 10:55:04 -0400 From: "Theodore Ts'o" 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=us-ascii Content-Disposition: inline In-Reply-To: <20220705190121.293703-1-Jason@zx2c4.com> Precedence: bulk List-ID: X-Mailing-List: linux-s390@vger.kernel.org On Tue, Jul 05, 2022 at 09:01:21PM +0200, Jason A. Donenfeld wrote: > Later the thinking evolved. With a properly designed RNG, using RDRAND > values alone won't harm anything, even if the outputs are malicious. I personally think it's totally fine to remove nordrand. However, the reason why it was there was that there were some rather extreme tin-foil-hatters who believed that if (the completely unavailable to the public for auditing) RDRAND implementation *were* malicious *and* the microcode had access to the register file and/or the instruction pipeline, then in theory, a malicious CPU could subvert how the RDRAND is mixed into the getrandom output to force a particular output. Personally, I've always considered it to be insane, since a much easier way to compromise a CPU would be to drop a Minix system hidden into the CPU running a web server that had massive security bugs in it that were only discovered years later. And if you don't trust the CPU manufacture to that extent, you should probably simply not use CPU's from that manufacturer. :-) - Ted 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 5F361C43334 for ; Wed, 6 Jul 2022 14:59:21 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4LdN3q34Ckz3c5b for ; Thu, 7 Jul 2022 00:59:19 +1000 (AEST) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=mit.edu header.i=@mit.edu header.a=rsa-sha256 header.s=outgoing header.b=jicRkedU; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=mit.edu (client-ip=18.9.28.11; helo=outgoing.mit.edu; envelope-from=tytso@mit.edu; receiver=) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=mit.edu header.i=@mit.edu header.a=rsa-sha256 header.s=outgoing header.b=jicRkedU; dkim-atps=neutral X-Greylist: delayed 166 seconds by postgrey-1.36 at boromir; Thu, 07 Jul 2022 00:58:41 AEST Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 4LdN356L5Wz3blD for ; Thu, 7 Jul 2022 00:58:40 +1000 (AEST) Received: from cwcc.thunk.org (pool-173-48-118-63.bstnma.fios.verizon.net [173.48.118.63]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 266Et4Za026327 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 6 Jul 2022 10:55:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing; t=1657119313; bh=ifFZJvbfIGVslUHWRDtftSqDp9BgS1ySpd5as638KpQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=jicRkedUge0cSrNp9dsPHkw4QFRERSGTRFWvzKMGECE7ezizOgSv9HxyR9V4F8S7F B3Z4cvkvhwTV+vUCLQyyRapiOOXIrh6qq6H06KmAU7CGQ4aXhLrDnNGj3ClQF1Na0r MfGlG/hzw6ibcSaN/qBTJnkql+Zzo+d40NlqpzyzX5ybtU1W3uQ2ySVzntVa7l0jYs tkDnbU64G7GfM2KZH9XpIvp8dnasZ7d1RvfrjUt2khPyFMDRUSqvqcK3+Ex61hsi7X BhyDG4ghY/zpMytxNISsWRBgmgGJllOR34RpeYEAVqRhNsCrgwz8QoCs3CgyKgd2Qk zZPwW6kHfDl3A== Received: by cwcc.thunk.org (Postfix, from userid 15806) id 75A9215C3E94; Wed, 6 Jul 2022 10:55:04 -0400 (EDT) Date: Wed, 6 Jul 2022 10:55:04 -0400 From: "Theodore Ts'o" 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=us-ascii Content-Disposition: inline In-Reply-To: <20220705190121.293703-1-Jason@zx2c4.com> 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:01:21PM +0200, Jason A. Donenfeld wrote: > Later the thinking evolved. With a properly designed RNG, using RDRAND > values alone won't harm anything, even if the outputs are malicious. I personally think it's totally fine to remove nordrand. However, the reason why it was there was that there were some rather extreme tin-foil-hatters who believed that if (the completely unavailable to the public for auditing) RDRAND implementation *were* malicious *and* the microcode had access to the register file and/or the instruction pipeline, then in theory, a malicious CPU could subvert how the RDRAND is mixed into the getrandom output to force a particular output. Personally, I've always considered it to be insane, since a much easier way to compromise a CPU would be to drop a Minix system hidden into the CPU running a web server that had massive security bugs in it that were only discovered years later. And if you don't trust the CPU manufacture to that extent, you should probably simply not use CPU's from that manufacturer. :-) - Ted 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 72F1FC43334 for ; Wed, 6 Jul 2022 14:56:55 +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=Hdp3xFY1Wnp4DYuKlt4RBqsY0Z6BrAqlxZ5Lf4DFItg=; b=bTG2vZvQeVApyx FG8cM1tOQkbouk84E3RPwj39Vt2lMkdQZ/Mu5gwrdKrVtU2LZ1HPqF6a3noFtVv2ZRJ0LuGTruPDY qj6veo+E53E4Z5iVLqzwhUvNPm+EqpSkJ76/qFj/1TrFdpf2WtNOszNnoJFVf7+PfmUdf6fmKci1W NC/lVeQ2/OFxgPfUP3pXK3tPXwFp19+/PhVU3Mg4v48mczWNiASANsxIv3Mal1oEgKbWzQ2SKJPBj rUtHOhrDbuGg65huXkpt8NzdchXz7FP+z1YhZ6+ISBVW5ZZLpZkTq1xP0S2c9In5TX3kcuDNiJIjN iHULOQiXSpaWckV3CTeQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1o96RR-00AqrM-UO; Wed, 06 Jul 2022 14:55:50 +0000 Received: from outgoing-auth-1.mit.edu ([18.9.28.11] helo=outgoing.mit.edu) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1o96RO-00Aqqg-Ph for linux-arm-kernel@lists.infradead.org; Wed, 06 Jul 2022 14:55:48 +0000 Received: from cwcc.thunk.org (pool-173-48-118-63.bstnma.fios.verizon.net [173.48.118.63]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 266Et4Za026327 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 6 Jul 2022 10:55:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing; t=1657119313; bh=ifFZJvbfIGVslUHWRDtftSqDp9BgS1ySpd5as638KpQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=jicRkedUge0cSrNp9dsPHkw4QFRERSGTRFWvzKMGECE7ezizOgSv9HxyR9V4F8S7F B3Z4cvkvhwTV+vUCLQyyRapiOOXIrh6qq6H06KmAU7CGQ4aXhLrDnNGj3ClQF1Na0r MfGlG/hzw6ibcSaN/qBTJnkql+Zzo+d40NlqpzyzX5ybtU1W3uQ2ySVzntVa7l0jYs tkDnbU64G7GfM2KZH9XpIvp8dnasZ7d1RvfrjUt2khPyFMDRUSqvqcK3+Ex61hsi7X BhyDG4ghY/zpMytxNISsWRBgmgGJllOR34RpeYEAVqRhNsCrgwz8QoCs3CgyKgd2Qk zZPwW6kHfDl3A== Received: by cwcc.thunk.org (Postfix, from userid 15806) id 75A9215C3E94; Wed, 6 Jul 2022 10:55:04 -0400 (EDT) Date: Wed, 6 Jul 2022 10:55:04 -0400 From: "Theodore Ts'o" 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: <20220705190121.293703-1-Jason@zx2c4.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220706_075547_029518_CB6431D7 X-CRM114-Status: GOOD ( 13.92 ) 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:01:21PM +0200, Jason A. Donenfeld wrote: > Later the thinking evolved. With a properly designed RNG, using RDRAND > values alone won't harm anything, even if the outputs are malicious. I personally think it's totally fine to remove nordrand. However, the reason why it was there was that there were some rather extreme tin-foil-hatters who believed that if (the completely unavailable to the public for auditing) RDRAND implementation *were* malicious *and* the microcode had access to the register file and/or the instruction pipeline, then in theory, a malicious CPU could subvert how the RDRAND is mixed into the getrandom output to force a particular output. Personally, I've always considered it to be insane, since a much easier way to compromise a CPU would be to drop a Minix system hidden into the CPU running a web server that had massive security bugs in it that were only discovered years later. And if you don't trust the CPU manufacture to that extent, you should probably simply not use CPU's from that manufacturer. :-) - Ted _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel