linux-kernel - Re: [PATCH v9 10/27] gunyah: rsc

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: <873fff36-7556-95f3-19e8-d172e8b4e47d@quicinc.com>
Date:   Mon, 6 Feb 2023 09:38:29 -0800
From:   Elliot Berman <quic_eberman@...cinc.com>
To:     Alex Elder <elder@...aro.org>,
        Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
        Bjorn Andersson <quic_bjorande@...cinc.com>,
        Murali Nalajala <quic_mnalajal@...cinc.com>
CC:     Trilok Soni <quic_tsoni@...cinc.com>,
        Srivatsa Vaddagiri <quic_svaddagi@...cinc.com>,
        Carl van Schaik <quic_cvanscha@...cinc.com>,
        Prakruthi Deepak Heragu <quic_pheragu@...cinc.com>,
        Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
        Arnd Bergmann <arnd@...db.de>,
        "Greg Kroah-Hartman" <gregkh@...uxfoundation.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Jonathan Corbet <corbet@....net>,
        Bagas Sanjaya <bagasdotme@...il.com>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>, Marc Zyngier <maz@...nel.org>,
        Jassi Brar <jassisinghbrar@...il.com>,
        Sudeep Holla <sudeep.holla@....com>,
        <linux-arm-msm@...r.kernel.org>, <devicetree@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <linux-doc@...r.kernel.org>,
        <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v9 10/27] gunyah: rsc_mgr: Add VM lifecycle RPC



On 2/6/2023 7:41 AM, Alex Elder wrote:
> On 2/2/23 6:46 AM, Srinivas Kandagatla wrote:
>>> +    ret = gh_rm_call(rm, message_id, &req_payload, 
>>> sizeof(req_payload), &resp, &resp_size);
>>> +    if (!ret && resp_size) {
>>
>> Am struggling to understand these type of checks in success case, when 
>> a command is not expecting any response why are we checking for 
>> response here, This sounds like a bug in either RM or hypervisor.
>>
>> Or Is this something that happens due to some firmware behaviour?
>> Could you elobrate on this.
> 
> What I think you're talking about is error checking even when
> it's very clear something "can't happen."  It's a pattern I've
> seen in Qualcomm downstream code, and I believe sometimes it
> is done as "best practice" to avoid warnings from security scans.
> (I might be wrong about this though.)

That's right reasoning.

> 
> I think your underlying point though is that we can just assume
> success means "truly successful," so there's no reason to do any
> additional sanity checks.  We *assume* the hardware is doing the
> correct thing (if it's not, we might as well assume it does
> *nothing* right). >
> So as a very general statement, I think all checks of this type
> should go away (and I think Srini would agree).
> 

I'll remove the checks.