linux-kernel - Re: [RFC PATCH 0/1] Add driver to read secondary bootloader (XBL) log

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20230828192011.GD818859@hu-bjorande-lv.qualcomm.com>
Date:   Mon, 28 Aug 2023 12:20:11 -0700
From:   Bjorn Andersson <quic_bjorande@...cinc.com>
To:     Trilok Soni <quic_tsoni@...cinc.com>
CC:     Arun Kumar Neelakantam <quic_aneelaka@...cinc.com>,
        Ninad Naik <quic_ninanaik@...cinc.com>, <agross@...nel.org>,
        <andersson@...nel.org>, <konrad.dybcio@...aro.org>,
        <psodagud@...cinc.com>, <quic_ppareek@...cinc.com>,
        <quic_kprasan@...cinc.com>, <linux-kernel@...r.kernel.org>,
        <linux-arm-msm@...r.kernel.org>, <kernel@...cinc.com>
Subject: Re: [RFC PATCH 0/1] Add driver to read secondary bootloader (XBL) log

On Mon, Aug 28, 2023 at 11:44:08AM -0700, Trilok Soni wrote:
> On 8/28/2023 10:19 AM, Arun Kumar Neelakantam wrote:
> > 
> > 
> > On 8/22/2023 5:45 PM, Ninad Naik wrote:
> >> Boot time logs for Qualcomm secondary boot-loader or XBL can help to
> >> identify different set of information regarding firmware configuration,
> >> SoC boot KPIs. A dedicated region is carved out in the memory map in order
> >> to store this log in the memory.
> >>
> >> The objective of this driver is to read the XBL boot log stored in
> >> this memory region post boot-up, and provide an entry in debugfs, which
> >> can be used to read back the logs and print them on to the console.
> >>
> > 
> > I see couple of use cases for this kind of logging like logs from
> > boot, Hypervisor, Trusted Execution environments and also one in
> > upstream for chromeos EC console. Can this be made a generic driver
> > which take log name, log memory buffer address and size to read from
> > debugfs.
> 
> The one downside of generic solution here is that log format may not
> be consistent. Some may have binary format of logs which will need
> further parsing in kernel or userspace. 
> 
> If we need to make such feature generic then it needs to be generic
> across arm64 / arm32 then and not SOC specific. 
> 

More importantly, it should provide a consistent interface towards the
consumer of the data, so that one wouldn't need a custom app to collect
every type of data.

Regards,
Bjorn