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]

Message-ID: <c555ec04-f8fd-4024-142b-123cdbb51e52@broadcom.com>
Date:   Thu, 1 Oct 2020 15:34:27 -0700
From:   Scott Branden <scott.branden@...adcom.com>
To:     Florian Fainelli <f.fainelli@...il.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 2020-09-30 7:38 p.m., Florian Fainelli wrote:
>
>
> 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
yes, commented in the patch.  we'll look at it.
>
> - cannot the firmware loading be supported over remoteproc somehow?
It doesn't follow remoteproc usage, Olof commented.
>
> - could not the TTY interface be using virtio or an existing UART?
commented in the patch.  I don't see how that would work with existing solutions but open to a simple solution if such exists.
>
> - what is the format of the message over BAR2 that you expose in patch 13?
proprietary log messages retrieve via user space app and run through post processing
>
> Is there a reference user-space implementation that you can link to this patch submission in case people are curious?
Published and commented to Greg K-H about this yesterday.

Here is the vk interface library, vkil, and associated unittest and card utilities.

https://github.com/Broadcom/vkil/


>
> Thanks


Download attachment "smime.p7s" of type "application/pkcs7-signature" (4169 bytes)