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 X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CFF27C3A59E for ; Wed, 21 Aug 2019 16:22:12 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A6B1222CE3 for ; Wed, 21 Aug 2019 16:22:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728970AbfHUQWL (ORCPT ); Wed, 21 Aug 2019 12:22:11 -0400 Received: from outgoing-auth-1.mit.edu ([18.9.28.11]:56373 "EHLO outgoing.mit.edu" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727975AbfHUQWL (ORCPT ); Wed, 21 Aug 2019 12:22:11 -0400 Received: from callcc.thunk.org (75-104-87-59.mobility.exede.net [75.104.87.59] (may be forged)) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x7LGLQaP017370 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 21 Aug 2019 12:21:33 -0400 Received: by callcc.thunk.org (Postfix, from userid 15806) id 2CA8742049E; Wed, 21 Aug 2019 12:21:26 -0400 (EDT) Date: Wed, 21 Aug 2019 12:21:26 -0400 From: "Theodore Y. Ts'o" To: Ard Biesheuvel Cc: Hsin-Yi Wang , "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" , Rob Herring , Devicetree List , lkml , Frank Rowand , Catalin Marinas , Will Deacon , Andrew Morton , Mike Rapoport , Miles Chen , James Morse , Andrew Murray , Mark Rutland , Jun Yao , Yu Zhao , Robin Murphy , Laura Abbott , Stephen Boyd , Kees Cook Subject: Re: [PATCH v8 2/3] fdt: add support for rng-seed Message-ID: <20190821162126.GA2713@mit.edu> Mail-Followup-To: "Theodore Y. Ts'o" , Ard Biesheuvel , Hsin-Yi Wang , "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" , Rob Herring , Devicetree List , lkml , Frank Rowand , Catalin Marinas , Will Deacon , Andrew Morton , Mike Rapoport , Miles Chen , James Morse , Andrew Murray , Mark Rutland , Jun Yao , Yu Zhao , Robin Murphy , Laura Abbott , Stephen Boyd , Kees Cook References: <20190819071602.139014-1-hsinyi@chromium.org> <20190819071602.139014-3-hsinyi@chromium.org> <20190819181349.GE10349@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Aug 21, 2019 at 09:39:28AM +0300, Ard Biesheuvel wrote: > > Whether to trust the firmware provided entropy is a policy decision, > and typically, we try to avoid dictating policy in the kernel, and > instead, we try to provide a sane default but give the user control > over it. > > So in this case, we should probably introduce > add_firmware_randomness() with a Kconfig/cmdline option pair to decide > whether it should be trusted or not (or reuse the one we have for > trusting RDRAND etc) I'd call it add_bootloader_randomness(), since we are trusting the *bootloader*; it's the bootloader which is vouching for the security / validity of the passed-in entropy. Furthermore, the bootloader on some architectures might be fetching directly from some secure element. And for that reason, I'd use a different Kconfig/cmdline option pair than the one used for trusting CPU-provided randomness. - Ted