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 D85BCC433F5 for ; Fri, 4 Feb 2022 05:55:09 +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:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=XCciM9vq9QamRras1oafoGaf+aTKwhANw2gM9kdRgt0=; b=CH92b8usu949V0 a+3OESbxLkaxL9IEBiJFq5JijEiLazp9FmdNQxkqW07lnzlVejglt3OQwBG5kiCDzdGspc8ev3JD5 Lxn/CizL29AiAcpRcuakLwv3+nzQAyXJZDOulsmRl3sPWYUyCLMdSX/AaCC4Ymp+Ys2AxNBjLUd6K oUc/tf3Vz6ooK6hcwLZW0YaF35czGYsn4VvnGsKEwPGXxtSB0fvqLjX28A3QS/Q9LVZmWk4Jt0DI4 yTYbaASMr/KfYN0IIPefrVFsn9C95WNBgA5Pa26gN9dEpJU5b78oWbavyUBtgu17XBaT0VEbLgjaK r/1IQ/4lCLm4GL6xfi/w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nFrXL-003XLY-RW; Fri, 04 Feb 2022 05:53:35 +0000 Received: from mail-qv1-xf30.google.com ([2607:f8b0:4864:20::f30]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nFrXI-003XLA-Eo for linux-arm-kernel@lists.infradead.org; Fri, 04 Feb 2022 05:53:34 +0000 Received: by mail-qv1-xf30.google.com with SMTP id d8so4585346qvv.2 for ; Thu, 03 Feb 2022 21:53:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jms.id.au; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eYsZplQCWhMg5A+bT/pC03ERRgBVVGDzmghNtqEQDr0=; b=YBivNNSPLPS90P9KanrM2iXgWGM9hWxwxA3cqwPEs0O+rRpVly9+LQwEvvJEX+WosN Cw8s0KI5wt9MO3OpPlCUiGTFse+3KKZ/AzysoAgshKxrQySVr9haOsvZXRi5+VroDUz8 BTE63MbJ+nz1+UP0MXiQKKvLtuGnwItdTM2yI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=eYsZplQCWhMg5A+bT/pC03ERRgBVVGDzmghNtqEQDr0=; b=rLrbNpRUuxDFD/DGaIQlhMPF5ZPXEKSKqh+lLk0TQJJX6nlgVrg0KgS2It34QHDcEd I2ZOSQiKGRjpjXv/BKKWmMDcbHNG9Ibw+rgl+/rwsvc5a6ExVcpC7R5ORaN6POCN6B1x lN8SLNEYMHnArQHSftfOd+e8hHTMRLapH2X1ioD7WSdGDbvmQKcmsghO4EXxv0bMY58R uAr4026Z37Cdd2IBRgoSsd5nkvfQ/G1LUaS3bqmGV0eHkMz6mmzHXYqSHFFl5b5IEaUE qG4lHjNp+oddBV8TXLhtVAgfIl578Sf61gmWCB6gwpLh43sVwcFiDYJvzxfsjS/D8/qm nBAQ== X-Gm-Message-State: AOAM530JX3SbOhT6SiAgb56OEhn+5lgRuYgqPn4LvLe0wRmrfjIxZ2eD bB9nMlUPlyN5yJxBNwoZgntCYQQxrdPf9hhA02Q= X-Google-Smtp-Source: ABdhPJxzV9x3lo5VCczp8QlRvauAgQ3xtN6M8nj+/uAMvK/1xvpmzR2BHbFocweO2eKRTPo+WwYrOvSqosvPmjV5APE= X-Received: by 2002:ad4:5f89:: with SMTP id jp9mr815712qvb.130.1643954011111; Thu, 03 Feb 2022 21:53:31 -0800 (PST) MIME-Version: 1.0 References: <20220203115344.267159-1-joel@jms.id.au> <20220203115344.267159-2-joel@jms.id.au> In-Reply-To: From: Joel Stanley Date: Fri, 4 Feb 2022 05:53:18 +0000 Message-ID: Subject: Re: [PATCH v2 1/3] firmware: Add boot information to sysfs To: Robin Murphy Cc: Arnd Bergmann , Andrew Jeffery , Greg Kroah-Hartman , "Rafael J . Wysocki" , Linux Kernel Mailing List , Linux ARM , linux-aspeed X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220203_215332_759195_F3CC8D42 X-CRM114-Status: GOOD ( 27.89 ) 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 Thu, 3 Feb 2022 at 14:23, Robin Murphy wrote: > > diff --git a/Documentation/ABI/testing/sysfs-firmware-bootinfo b/Documentation/ABI/testing/sysfs-firmware-bootinfo > > new file mode 100644 > > index 000000000000..cd6c42316345 > > --- /dev/null > > +++ b/Documentation/ABI/testing/sysfs-firmware-bootinfo > > @@ -0,0 +1,43 @@ > > +What: /sys/firmware/bootinfo/* > > +Date: Jan 2022 > > +Description: > > + A system can expose information about how it was started in > > + this directory. > > + > > + This information is agnostic as to the firmware implementation. > > + > > + A system may expose a subset of these properties as applicable. > > + > > + > > +What: /sys/firmware/bootinfo/secure_boot > > +Date: Jan 2022 > > +Description: > > + Indicates the system was started with secure boot enabled in > > + the firmware. > > + > > + > > +What: /sys/firmware/bootinfo/abr_image > > +Date: Jan 2022 > > +Description: > > + Indicates the system was started from the alternate image > > + loaded from an Alternate Boot Region. Often this is a result of > > + the primary firmware image failing to start the system. > > + > > + > > +What: /sys/firmware/bootinfo/low_security_key > > +Date: Jan 2022 > > +Description: > > + Indicates the system's secure boot was verified with a low > > + security or development key. > > + > > +What: /sys/firmware/bootinfo/otp_protected > > +Date: Jan 2022 > > +Description: > > + Indicates the system's boot configuration region is write > > + protected and cannot be modified. > > + > > +What: /sys/firmware/bootinfo/uart_boot > > +Date: Jan 2022 > > +Description: > > + Indicates the system firmware was loaded from a UART instead of > > + an internal boot device. > > I'd be concerned about how well details like "uart_boot" and "abr_image" > scale beyond one SoC family from one vendor. The combinatorial explosion > of possible boot configurations across Linux-capable SoCs and firmware > in general is larger than I'd care to imagine, even before considering > that the nuances don't necessarily stop there - e.g. whether a given > storage interface is hard-wired or user-accessible is not a fixed > property on many SoCs, and even a socketed SD card might be "trusted" if > a board is deployed in a product with a sealed enclosure. This is a fair point. The first iteration of this idea was specific to the aspeed soc. For the system I'm building, secure_boot and otp_locked tell our manufacturing test process that the machine has been correctly provisioned. I'd like to get something agreed upon so we can start using those sysfs files in the testing without having to go back and change things. abr_image is an indication that something went wrong at boot time. I thought this was a standard eMMC concept, but taking a closer look it's specific to the aspeed soc. Would it help if we gave them generic names? - abr_image -> alternate_boot I welcome other suggestions. I'll drop the uart_boot property for now. Cheers, Joel _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel