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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Fri, 21 Feb 2020 09:44:35 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     Scott Branden <scott.branden@...adcom.com>
Cc:     Luis Chamberlain <mcgrof@...nel.org>, Takashi Iwai <tiwai@...e.de>,
        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 <bjorn.andersson@...aro.org>,
        Shuah Khan <skhan@...uxfoundation.org>,
        "Rafael J . Wysocki" <rafael@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        linux-arm-msm <linux-arm-msm@...r.kernel.org>,
        Linux FS-devel Mailing List <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>,
        "open list:KERNEL SELFTEST FRAMEWORK" 
        <linux-kselftest@...r.kernel.org>
Subject: Re: [PATCH 2/7] firmware: add offset to request_firmware_into_buf

On Fri, Feb 21, 2020 at 1:11 AM Scott Branden
<scott.branden@...adcom.com> wrote:
> On 2019-10-11 6:31 a.m., Luis Chamberlain wrote:
> > On Tue, Aug 27, 2019 at 12:40:02PM +0200, Takashi Iwai wrote:
> >> On Mon, 26 Aug 2019 19:24:22 +0200,
> >> Scott Branden wrote:
> >>> I will admit I am not familiar with every subtlety of PCI
> >>> accesses. Any comments to the Valkyrie driver in this patch series are
> >>> appreciated.
> >>> But not all drivers need to work on all architectures. I can add a
> >>> depends on x86 64bit architectures to the driver to limit it to such.
> >> But it's an individual board on PCIe, and should work no matter which
> >> architecture is?  Or is this really exclusive to x86?
> >
> > Poke Scott.
>
> Yes, this is exclusive to x86.
> In particular, 64-bit x86 server class machines with PCIe gen3 support.
> There is no reason for these PCIe boards to run in other lower end
> machines or architectures.

It doesn't really matter that much what you expect your customers to
do with your product, or what works a particular machine today, drivers
should generally be written in a portable manner anyway and use
the documented APIs. memcpy() into an __iomem pointer is not
portable and while it probably works on any x86 machine today, please
just don't do it. If you use 'sparse' to check your code, that would normally
result in an address space warning, unless you add __force and a
long comment explaining why you cannot just use memcpy_to_io()
instead. At that point, you are already better off usingn memcpy_to_io() ;-)

        Arnd