linux-kernel - Re: [PATCH v5 00/15] Add Broadcom VK driver

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:   Wed, 30 Sep 2020 19:38:56 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Scott Branden <scott.branden@...adcom.com>,
        Arnd Bergmann <arnd@...db.de>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Olof Johansson <olof@...om.net>
Cc:     Kees Cook <keescook@...omium.org>, linux-kernel@...r.kernel.org,
        bcm-kernel-feedback-list@...adcom.com
Subject: Re: [PATCH v5 00/15] Add Broadcom VK driver



On 9/30/2020 6:27 PM, Scott Branden wrote:
> This patch series drops previous patches in [1]
> that were incorporated by Kees Cook into patch series
> "Introduce partial kernel_read_file() support" [2].
> 
> Remaining patches are contained in this series to add Broadcom VK driver.
> (which depends on request_firmware_into_buf API addition in
> other patch series [2] being applied first).
> 
> Please note this patch series will not compile without [2].
> 
> [1] https://lore.kernel.org/lkml/20200706232309.12010-1-scott.branden@broadcom.com/
> [2] https://lore.kernel.org/lkml/20200729175845.1745471-1-keescook@chromium.org/

Disclaimer: I am well aware that it is the complete wild west right now 
as far as accelerators go and that every vendor (that I happen to work 
for, just not in the same group as Scott) is just seeking to get their 
drivers included upstream and hopefully for good reasons.

 From a cursory look however, it sounds like there could be a little 
better re-utilization of standards, standard framework and interfaces:

- about 2/3 of your sysfs attributes should incline you to implement a 
HWMON device, not a complicated one, but anything that indicates 
current, power, temperature, alerts etc. should be considered

- cannot the firmware loading be supported over remoteproc somehow?

- could not the TTY interface be using virtio or an existing UART?

- what is the format of the message over BAR2 that you expose in patch 13?

Is there a reference user-space implementation that you can link to this 
patch submission in case people are curious?

Thanks
-- 
Florian