Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp1210679ybv; Fri, 7 Feb 2020 16:51:38 -0800 (PST) X-Google-Smtp-Source: APXvYqwfaQzXk7m41t2EQaQvoh79K+yd4k3hQ2bNnYsHmToEDfZed0B8GA8TNfFo8GxDXf/jv2eS X-Received: by 2002:a54:4707:: with SMTP id k7mr3685045oik.153.1581123098325; Fri, 07 Feb 2020 16:51:38 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1581123098; cv=none; d=google.com; s=arc-20160816; b=oPqTEfMylVzTbfSYF7LalSmn0TOsu5f+VTJj/hDCPZTdYmoAw33hdtgZrPLJ3E4C/K JAI4N/hsvBfiUuhTqqbIVvdvu2RVWsarHDclqei+oMlouJyI0psmrACEvopymPBeZ+6E nzRom5ayS5XBXxi780F2DGQnOZ7097NhNuucglVb3EkMOIsJz1YTUGOlpWUlkoTCHekw G68FOK4hWqNg5TEOx3uG3nVsqkqaSwvhEI+nGK4WOD6r7AiGP1V4m1kLwJHmdL8LgOFG 62SCqx9LfbXqVble/x9BY7IchPHjyCS9sOemgTEyfv48AycAzGfHzgjF2RJT/J0VnaOw oOrQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=PKoGPBzAs+RRfOUpkJrsUnXb2drONH9VU4hqE2N47uw=; b=CVL8dGOMveyixHRHufbXcqCG/7nECXAJ3BJezOvLNb7dpV+vWEQdMLBzKTwN4B4I8S jOR/r/19fYoYSYvO3dHLN2MTpGPBX+6eMEs3BsIBS/LaZCLY8tLe6a3Kbhq+k+4611K0 Md3mNCSASTf9sERID9Z8jK/uAB7m/iliNlIVAN0I+W1MQ+EQgE1RVwBhnmLFIIFtQfq9 R4dozU9a9hnC2p2cQfNekvpCCndQ5mkXrNP8mIWbsHW91+dbfchxmmM7TEfCtaaVv0sO Q5iLWwfIelKlswfBpPfbWXQhpQ+wu7wypCodMwqUe5pe9NjNnwI6WsBL+rMFTNUQp5E1 OQPQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n186si4599453oig.191.2020.02.07.16.51.26; Fri, 07 Feb 2020 16:51:38 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727381AbgBHAuS (ORCPT + 99 others); Fri, 7 Feb 2020 19:50:18 -0500 Received: from outgoing-auth-1.mit.edu ([18.9.28.11]:53822 "EHLO outgoing.mit.edu" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727131AbgBHAuS (ORCPT ); Fri, 7 Feb 2020 19:50:18 -0500 Received: from callcc.thunk.org (guestnat-104-133-0-101.corp.google.com [104.133.0.101] (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 0180nMPw011787 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 7 Feb 2020 19:49:23 -0500 Received: by callcc.thunk.org (Postfix, from userid 15806) id 88C16420324; Fri, 7 Feb 2020 19:49:22 -0500 (EST) Date: Fri, 7 Feb 2020 19:49:22 -0500 From: "Theodore Y. Ts'o" To: Mark Salyzyn Cc: linux-kernel@vger.kernel.org, kernel-team@android.com, Arnd Bergmann , Greg Kroah-Hartman , Richard Henderson , Mark Brown , Kees Cook , Hsin-Yi Wang , Vasily Gorbik , Andrew Morton , Masami Hiramatsu , "Steven Rostedt (VMware)" , Mike Rapoport , Arvind Sankar , Dominik Brodowski , Thomas Gleixner , Alexander Potapenko Subject: Re: [PATCH] random: add rng-seed= command line option Message-ID: <20200208004922.GE122530@mit.edu> References: <20200207150809.19329-1-salyzyn@android.com> <20200207155828.GB122530@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Feb 07, 2020 at 09:49:17AM -0800, Mark Salyzyn wrote: > > > It is preferred to add rng-seed to the Device Tree, but some > > > platforms do not have this option, so this adds the ability to > > > provide some command-line-limited data to the entropy through this > > > alternate mechanism. Expect all 8 bits to be used, but must exclude > > > space to be accounted in the command line. > > "all 8 bits"? > > Command line (and Device Tree for that matter) can provide 8-bits of data, > and specifically for the command line as long as they skip space and nul > characters, we will be stripping the content out of the command line because > we strip it from view, so that no one gets hot and bothered. What wasn't obvious to me initially (and should be clearly documented in the commit description as well as elsewhere) is that we are already adding the entire boot command-line string using "add_device_randomness()" and so what this commit is doing is simply counting the length of xxx in "rng_seed=xxx" and assuming that those bytes are 100% entropy and simply crediting the trusted entropy by length of xxx. If xxx happened to be a hex string, or worse, was hard-coded in /etc/grub.conf as "rng_seed=supercalifragilisticexpialidocious" with this commit (and CONFIG_RANDOM_TRUST_BOOTLOADER), it would assume that it is safe to credit the boot command line has having sufficient entropy to fully initialize the CRNG. > I expected this to be contentious, this is why I call it out. Does _anyone_ > have a disagreement with allowing raw data (minus nul and space characters) > to be part of the rng-seed? There are two parts of this that might be controverisial. The first is that there isn't actually *fully* eight bits; it's really log_2(254) bits per caharacter, since NUL and SPC aren't valid. The second is that we're treating rng_seed as being magic, and if someone tries to pass in something like rng_seed=0x7932dca76b51 because they didn't understand how rng_seed was going to work, it would be surprising. My preference would be to pass in the random seed *not* on the command-line at all, but as a separate parameter which is passed to the bootloader, just as we pass in the device-tree, the initrd and the command-line as separate things. The problem is that how we pass in extra boot parameters is architecture specific, and how we might do it for x86 is different than for arm64. So yeah, it's a bit more inconvenient to do things that way; but I think it's also much cleaner. - Ted