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]
Date:   Mon, 28 Aug 2023 11:44:08 -0700
From:   Trilok Soni <quic_tsoni@...cinc.com>
To:     Arun Kumar Neelakantam <quic_aneelaka@...cinc.com>,
        Ninad Naik <quic_ninanaik@...cinc.com>, <agross@...nel.org>,
        <andersson@...nel.org>, <konrad.dybcio@...aro.org>
CC:     <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 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. 


-- 
---Trilok Soni

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ