Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp2319517ybv; Fri, 14 Feb 2020 16:17:50 -0800 (PST) X-Google-Smtp-Source: APXvYqw4kNP+NH002kZQxS/fPjyrC1EFcS3nQaU2x1mU7XwBXu4oLVwXboN6t0J8XbzPx0yRjiP4 X-Received: by 2002:a05:6830:1615:: with SMTP id g21mr4432357otr.49.1581725870051; Fri, 14 Feb 2020 16:17:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1581725870; cv=none; d=google.com; s=arc-20160816; b=kGOrBDruIlIL5XKG/+0X0P+Bs6+rc4koLn+v6g0ddDNB/iUNx1adVByiG3TvmFoNri Cw4ZcG/2uKXJVTbz/+npDAtHXXrq93zvZmMdJYSyAoPWrBa8HhHLyj768DAC5gBrGfml viHvJZxXZyShP0+kqdLdbn+HPGfK9XY/H2aQp+wn7r1moi/OocPCSjEJ4zmhzaDi/ME5 XaqCk+wPmgk6TccZdZD7AIvyLdJ0g8mH5hdUan2zK9n2gPhOrvH8RLbnZ/k4YHIPxmCr keRx8q4HMWxPWiHyiXC8eaP+t/s1uN52cnDzhJbhBPgaQvPxeZ7cPyyDtVyJsvtqH8ow Mbpg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=4Dm5YXZkpWfHmiMxBTbGnKCssef2pT/Txsf5MwpkME8=; b=E6Yr0mIdYddRZpfoN+ezwX0Vmd47puWePRZf7QevX8tN8COl8tZLHaasyzcaef1PAE V36mbG5W6md1UuX3JgMUa2QwUe5i/4hPkvPu/ZIGPNMCXA8lQosunnU4sga9snCHVn72 AX/UjkeX4u4Cl7uy364qvWZoMBZ7bY8rpLDWDNh5qGJ0vE8l3KBXvnxmPr+O1jufOan9 R/sKN0uj52FPUKBvZRMt7Ng3pFXqYlXYNuv9G8eeiu7f1Gt5sJXZ6cNnUsNcO05cGhro ohPYk/ufxCqs8x5valnDvEAaKh06rCfkvADaIziEG3OPPhhk2r8C1nu6b5FaztnpUROt At6w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=GQAwE8iB; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l6si3551479oti.249.2020.02.14.16.17.37; Fri, 14 Feb 2020 16:17:50 -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; dkim=pass header.i=@kernel.org header.s=default header.b=GQAwE8iB; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727683AbgBOAR1 (ORCPT + 99 others); Fri, 14 Feb 2020 19:17:27 -0500 Received: from mail.kernel.org ([198.145.29.99]:42602 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726079AbgBOAR1 (ORCPT ); Fri, 14 Feb 2020 19:17:27 -0500 Received: from devnote2 (NE2965lan1.rev.em-net.ne.jp [210.141.244.193]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id D9D93207FF; Sat, 15 Feb 2020 00:17:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1581725846; bh=0TKEdWN6SIgbxXSKWc4lndzp4gWiftZNNLwKKtQQyF4=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=GQAwE8iBhkKbW2wIezXRYLdvtYyBnfKcGq5xfMtirqsljp5zJjd4urdXNOvxfGGEk mnET3Wm7ehwMqXNv49e/b+0M59o6q8mtdASEHsfuOLbno/BsvX+fwfXljZmWZCjyxe Q7udDoqFD9xNFG3s+hEZ51hz3LV5oic0zuYXcX7g= Date: Sat, 15 Feb 2020 09:17:18 +0900 From: Masami Hiramatsu To: Rob Herring Cc: Mark Salyzyn , Masami Hiramatsu , "linux-kernel@vger.kernel.org" , Android Kernel Team , "Theodore Ts'o" , Arnd Bergmann , Greg Kroah-Hartman , Richard Henderson , Mark Brown , Kees Cook , Hsin-Yi Wang , Vasily Gorbik , Andrew Morton , Steven Rostedt , Mike Rapoport , Arvind Sankar , Dominik Brodowski , Thomas Gleixner , Alexander Potapenko , Jonathan Corbet , Mauro Carvalho Chehab , Josh Poimboeuf , Pawan Gupta , Juergen Gross , Linux Doc Mailing List Subject: Re: [PATCH 0/3] random: add random.rng_seed to bootconfig entry Message-Id: <20200215091718.129eecc9b65a9c41c91027b0@kernel.org> In-Reply-To: References: <158166060044.9887.549561499483343724.stgit@devnote2> <1694f42c-bfc9-570a-64d2-3984965c8940@android.com> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.32; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Rob, On Fri, 14 Feb 2020 12:14:53 -0600 Rob Herring wrote: > To clarify my question: Why do we need random seed in bootconfig > rather than just the kernel command line? I'm not understanding why > things changed from your original patch. I recommended to use it in the previous thread, because of simplicity. Since it has to hide from userspace and modules, it needs to modify kernel command line. But the bootconfig can make it simple, and it also architecture independent. > > In addition, 2B Android devices on the planet, especially in light of > > the Android GKI distribution were everything that is vendor created is > > in a module, needs a way to collect early entropy prior to module load > > and pass it to the kernel. Yes, they do have access to the recently > > added Device Tree approach, and we expect them to use it, as I have an > > active backport for the mechanism into the Android 4.19 and 5.4 kernels. FYI, I backported bootconfig with boot-time tracer for 4.19 stable kernel recently. https://github.com/mhiramat/linux/commits/ftrace-boottrace-4.19 You can check what commits are related. > > There may also be some benefit to allowing the 13000 different > > bootloaders an option to use bootconfig as a way of propagating the much > > needed entropy to their kernels. I could make a case to also allow them > > command line as another option to relieve their development stress to > > deliver product, but we can stop there. Regardless, this early entropy > > has the benefit of greatly improving security and precious boot time. > > We're going to update 13000 bootloaders to understand bootconfig > rather than use the infrastructure already in place (DT and/or command > line)? > > bootconfig is an ftrace feature only IMO. If it's more than that, I > imagine there will be some opinions about that. Adding new > bootloader-kernel interfaces is painful and not something to just add > without much review. The bootconfig itself is designed as a generic feature. I had tried to use devicetree, but that was rejected. Thus I made it as a "software configuration tree" (but far simpler.) If you have any review comment on the bootconfig, always welcome! Seriously, I would like to have more comments. I want to make it better. Thank you, -- Masami Hiramatsu