linux-kernel - Re: [PATCH v4 00/21] Add Qualcomm Minidump kernel driver related support

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: <9f054246-d134-25b5-75ee-ff5b4b78d8a4@quicinc.com>
Date:   Thu, 6 Jul 2023 11:07:08 -0700
From:   Trilok Soni <quic_tsoni@...cinc.com>
To:     Rob Herring <robh+dt@...nel.org>
CC:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
        Mukesh Ojha <quic_mojha@...cinc.com>,
        Greg KH <gregkh@...uxfoundation.org>, <corbet@....net>,
        <agross@...nel.org>, <andersson@...nel.org>,
        <konrad.dybcio@...aro.org>, <krzysztof.kozlowski+dt@...aro.org>,
        <conor+dt@...nel.org>, <keescook@...omium.org>,
        <tony.luck@...el.com>, <gpiccoli@...lia.com>,
        <mathieu.poirier@...aro.org>, <catalin.marinas@....com>,
        <will@...nel.org>, <linus.walleij@...aro.org>,
        <andy.shevchenko@...il.com>, <linux-doc@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <linux-arm-msm@...r.kernel.org>,
        <devicetree@...r.kernel.org>, <linux-hardening@...r.kernel.org>,
        <linux-remoteproc@...r.kernel.org>,
        <linux-arm-kernel@...ts.infradead.org>,
        <linux-gpio@...r.kernel.org>, Alex Elder <elder@...aro.org>
Subject: Re: [PATCH v4 00/21] Add Qualcomm Minidump kernel driver related
 support

On 7/6/2023 10:40 AM, Rob Herring wrote:
> On Mon, Jul 3, 2023 at 3:06 PM Trilok Soni <quic_tsoni@...cinc.com> wrote:
>>
>> On 7/2/2023 1:29 AM, Krzysztof Kozlowski wrote:
>>> On 30/06/2023 18:04, Mukesh Ojha wrote:
>>>>>
>>>>>> We don't add layers when they are not needed, and never when there is no
>>>>>> actual user.  If you need the extra "complexity" later, then add it
>>>>>> later when it is needed as who knows when that will ever be.
>>>>>>
>>>>>> Please redo this series based on that, thanks.
>>>>>
>>>>> My bigger issue with this whole series is what would this all look
>>>>> like if every SoC vendor upstreamed their own custom dumping
>>>>> mechanism. That would be a mess. (I have similar opinions on the
>>>>> $soc-vendor hypervisors.)
>>>
>>> Mukesh,
>>>
>>> LPC CFP is still open. There will be also Android and Kernel Debugging
>>> LPC microconference tracks. Coming with a unified solution could be a
>>> great topic for LPC. Solutions targeting only one user are quite often
>>> frowned upon.
>>
>> LPC is far out and in November. Can we not have others speak up if they
>> have the similar solution now? We can expand this to linux-kernel and
>> ask for the other SOC vendors to chime in. I am sure that we may have
>> existing solutions which came in for the one user first like Intel RDT
>> if I remember. I am sure ARM MPAM usecase was present at that time but
>> Intel RDT based solution which was x86 specific but accepted.
> 
> RDT predated MPAM. resctrl is the kernel feature, and it supports
> Intel and AMD which are not identical. resctrl is being (extensively)
> refactored to add in MPAM support.
> 
> You are not the first here like Intel RDT, so I fail to see the
> parallel with minidump. We have an existing logging to persistent
> storage mechanism which is pstore. You should integrate into that
> rather than grafting something on to the side or underneath.
> 

Mukesh will chime in once he looks at the hwtracing suggested by Linus W 
and see if it fits. Mukesh seems have already looked at pstore and 
discussions/patches are there w/ pstore logic I believe, but it is okay 
if they are not perfect if we are still not decided on the right 
framework. Best to decide if the existing frameworks fits or not or we 
need to create the new one.

I would still prefer if other SOC vendors chime in here, since I am sure 
in the Mobile and Embedded world various SOCs may have requirements to 
get specific portion of the ramdump only for the quick analysis and 
meeting the storage requirements on the device for its collection.

As mentioned on another patch, we are fine the submit abstract at LPC 
debug MC, but I would like the framework discussion to continue so that 
we can decide during the LPC that either existing frameworks fits the 
needs or they need to be extended or new fwk is needed.

---Trilok Soni