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 669A6C433EF for ; Tue, 5 Jul 2022 21:52:41 +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:MIME-Version:Message-ID:References: In-Reply-To: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=gC92c8ZNm7spjlJgOrTM5mZBqw1dTNxcVYEikCJg4ec=; b=SC1YUPYTELpebs wz8cWqRLBHsX+3kTiJVtkDbmMlGN8aysglJQp3oFQiJFUrAmF2uAtsHVMxh8jJcd3MCKADFMleRZ+ O1As/LHhVPrucjPQb19D6RmMCLh1xw8vpzyrJ8mahgfYOsuCSEisQBYsTqS80pv0Xff71ilGuCz1V kCFakAIB0stjGh4xb0jYwhuWSqnGgiq3W1Ssnffx1EzI7gZIsqY0BPjwbUNv1zj3oqfHw5MmDjSuC nVR/WFtjTLVRacZeAoSDbREVCmTzD5s9srtCTZ0RytwvyBbMUoX0qVs//T8ZPBoKijqj24EQYDw6z MtumA4s/4pUHMIJ1kkIQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1o8qRy-0030Hc-6O; Tue, 05 Jul 2022 21:51:18 +0000 Received: from terminus.zytor.com ([198.137.202.136] helo=mail.zytor.com) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1o8qRv-0030H2-CY for linux-arm-kernel@lists.infradead.org; Tue, 05 Jul 2022 21:51:16 +0000 Received: from [127.0.0.1] ([73.223.250.219]) (authenticated bits=0) by mail.zytor.com (8.17.1/8.15.2) with ESMTPSA id 265LoZui985421 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Tue, 5 Jul 2022 14:50:35 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 265LoZui985421 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com; s=2022060401; t=1657057837; bh=7KDE2gFVvMSgPsHGHe9MxJdE6fru6CX4ADvVbzCKtT8=; h=Date:From:To:CC:Subject:In-Reply-To:References:From; b=lMkaO2FbzS8H3Ku8woeLDFSXdgUMzhKC15vy7VQdtwYs91XormxkElNRd8Q0jV9i9 eiuEeplg9WtLAgD8dk0P/U/FI2JDZFmhH/T8n6gsuHuQypPNaaPgdlm8lcT3IA826d UzDQl4+77Pv22WQfoIiMSzqQxzQqc1IuTgDtDrtFRoVtuIPrsj1cfJx2OaI3ruVEcd ATP70kCNxi2r3ncyjkBZdYQrBeDR5ggdHco/GkfmlGdkVPVp5wGkZcp5fbUDTgWEvA 6N2BHP8z5Y/b0MLZ6XmVUItrHq/zFjRynAUVqUtBrK9SN/XxO0hSRnfBNnNNBVsgCi U/yxv4tY8favw== Date: Tue, 05 Jul 2022 14:50:34 -0700 From: "H. Peter Anvin" To: Borislav Petkov , "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 , Greg Kroah-Hartman , Arnd Bergmann Subject: Re: [PATCH] random: remove CONFIG_ARCH_RANDOM and "nordrand" User-Agent: K-9 Mail for Android In-Reply-To: References: <20220705190121.293703-1-Jason@zx2c4.com> Message-ID: <11C903CC-22A7-48EE-AD63-E71CC8D28B88@zytor.com> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220705_145115_454167_27EF14D4 X-CRM114-Status: GOOD ( 18.78 ) 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 July 5, 2022 12:57:04 PM PDT, Borislav Petkov wrote: >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. > It's just math. The only variable is your confidence level, i.e. at what level do you decide that the likelihood of pure chance is way smaller than the likelihood of hardware failure. For example, the likelihood of m n-bit samples in a row being identical is 2^-(n*(m-3/2)), and the likelihood of the CPU being destroyed by a meterorite in the same microsecond is about 2^-100. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel