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=-6.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, SPF_HELO_NONE,SPF_PASS autolearn=unavailable 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 EF1D1C35242 for ; Sat, 15 Feb 2020 00:17:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id BD0142082F for ; Sat, 15 Feb 2020 00:17:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1581725847; bh=0TKEdWN6SIgbxXSKWc4lndzp4gWiftZNNLwKKtQQyF4=; h=Date:From:To:Cc:Subject:In-Reply-To:References:List-ID:From; b=pLDW4skTle9LzX53s3/2DjcWlnmchTNIvDRLUEGaQGiy/jtThQ2c0Lm0GrXkZA1EU C8jEK4dPrgGPEv3TOLDzAQHlTqIYz81YnNyurbRC/Vz3eh7Xf78Z6jCuU645q25zAU B0exJsd35k1OhVT6doYL36B5eT9SePyatybDJ9+k= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727455AbgBOAR1 (ORCPT ); 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-doc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-doc@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