linux-kernel - Re: [PATCH v5 2/3] venus: Add a debugfs file for SSR trigger

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:   Thu, 16 Sep 2021 11:59:36 +0530
From:   dikshita@...eaurora.org
To:     Stephen Boyd <swboyd@...omium.org>
Cc:     Stanimir Varbanov <stanimir.varbanov@...aro.org>,
        linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-media@...r.kernel.org, jim.cromie@...il.com,
        Joe Perches <joe@...ches.com>, Jason Baron <jbaron@...mai.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-media-owner@...r.kernel.org,
        Akinobu Mita <akinobu.mita@...il.com>
Subject: Re: [PATCH v5 2/3] venus: Add a debugfs file for SSR trigger

On 2021-09-16 01:09, Stephen Boyd wrote:
> Quoting dikshita@...eaurora.org (2021-09-15 02:13:09)
>> Hi Stephen,
>> 
>> Reviving the discussion on this change as we need to pull this in.
>> 
>> As per your suggestion, I explored the fault injection framework to
>> implement this functionality.
>> But I don't think that meets our requirements.
>> 
>> We need a way to trigger subsystem restart from the client-side, it's
>> not derived from the driver.
> 
> Just to confirm, this is all for debugging purposes right?
> 
yes, correct. this is for debugging purposes. We need this to simulate 
an error on FW side.
In a normal scenario, when FW runs into error, sys error is triggered 
from FW as result of which
a sequence of commands are followed for restarting the system.
using this feature, we are trying to simulate this error on FW i.e we 
are forcing the FW to run into an error.
>> 
>> while fault injection framework enables the driver to trigger an
>> injection
>> when a specific event occurs for eg: page allocation failure or memory
>> access failure.
>> 
>> So, IMO, we will have to use custom debugfs only.
> 
> Can you use DECLARE_FAULT_ATTR()? Or you need it to be active instead 
> of
> passive, i.e. it shouldn't wait for should_fail() to return true, but
> actively trigger something on the remoteproc?
> 

yes, it doesn't need to wait for should_fail() to return true.
the client/user should be able to trigger this subsystem restart(SSR) at 
any point of time
when a session is running. It's totally client-driven.

>> 
>> Please feel free to correct me in case my understanding of the 
>> framework
>> is wrong.
>> 
> 
> I presume the fault injection framework could get a new feature that
> lets the fault be injected immediately upon writing the debugfs file.
> My goal is to consolidate this sort of logic into one place and then 
> put
> it behind some config option that distros can disable so the kernel
> isn't bloated with debug features that end users will never care about.