linux-kernel - Re: [PATCH 2/7] firmware: add offset to request_firmware_into

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 for Android: free password hash cracker in your pocket

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

Message-ID: <s5hef1crybq.wl-tiwai@suse.de>
Date:   Fri, 23 Aug 2019 12:05:45 +0200
From:   Takashi Iwai <tiwai@...e.de>
To:     Scott Branden <scott.branden@...adcom.com>
Cc:     Luis Chamberlain <mcgrof@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        David Brown <david.brown@...aro.org>,
        Alexander Viro <viro@...iv.linux.org.uk>,
        Shuah Khan <shuah@...nel.org>, bjorn.andersson@...aro.org,
        Shuah Khan <skhan@...uxfoundation.org>,
        Arnd Bergmann <arnd@...db.de>,
        "Rafael J . Wysocki" <rafael@...nel.org>,
        linux-kernel@...r.kernel.org, linux-arm-msm@...r.kernel.org,
        linux-fsdevel@...r.kernel.org,
        BCM Kernel Feedback <bcm-kernel-feedback-list@...adcom.com>,
        Olof Johansson <olof@...om.net>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Dan Carpenter <dan.carpenter@...cle.com>,
        Colin Ian King <colin.king@...onical.com>,
        Kees Cook <keescook@...omium.org>,
        linux-kselftest@...r.kernel.org
Subject: Re: [PATCH 2/7] firmware: add offset to request_firmware_into_buf

On Thu, 22 Aug 2019 21:24:46 +0200,
Scott Branden wrote:
> 
> Add offset to request_firmware_into_buf to allow for portions
> of firmware file to be read into a buffer.  Necessary where firmware
> needs to be loaded in portions from file in memory constrained systems.

AFAIU, this won't work with the fallback user helper, right?
Also it won't work for the compressed firmware files as-is.

So this new API usage is for the limited use cases, hence it needs
such checks and returns error/warns if the condition isn't met.

IOW, this can't be a simple extension of request_firmware_into_buf()
to pass a new flag.


thanks,

Takashi