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:   Tue, 1 Dec 2020 13:48:36 -0700
From:   Jeffrey Hugo <jhugo@...eaurora.org>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     Hemant Kumar <hemantk@...eaurora.org>,
        manivannan.sadhasivam@...aro.org, gregkh@...uxfoundation.org,
        linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org,
        bbhatt@...eaurora.org, loic.poulain@...aro.org,
        netdev@...r.kernel.org, linux-wireless@...r.kernel.org,
        Kalle Valo <kvalo@...eaurora.org>
Subject: Re: [PATCH v13 0/4] userspace MHI client interface driver

On 12/1/2020 1:03 PM, Jakub Kicinski wrote:
> On Tue, 1 Dec 2020 12:40:50 -0700 Jeffrey Hugo wrote:
>> On 12/1/2020 12:29 PM, Jakub Kicinski wrote:
>>> On Fri, 27 Nov 2020 19:26:02 -0800 Hemant Kumar wrote:
>>>> This patch series adds support for UCI driver. UCI driver enables userspace
>>>> clients to communicate to external MHI devices like modem and WLAN. UCI driver
>>>> probe creates standard character device file nodes for userspace clients to
>>>> perform open, read, write, poll and release file operations. These file
>>>> operations call MHI core layer APIs to perform data transfer using MHI bus
>>>> to communicate with MHI device. Patch is tested using arm64 based platform.
>>>
>>> Wait, I thought this was for modems.
>>>
>>> Why do WLAN devices need to communicate with user space?
>>>    
>>
>> Why does it matter what type of device it is?  Are modems somehow unique
>> in that they are the only type of device that userspace is allowed to
>> interact with?
> 
> Yes modems are traditionally highly weird and require some serial
> device dance I don't even know about.
> 
> We have proper interfaces in Linux for configuring WiFi which work
> across vendors. Having char device access to WiFi would be a step
> back.

So a WLAN device is only ever allowed to do Wi-Fi?  It can't also have 
GPS functionality for example?

> 
>> However, I'll bite.  Once such usecase would be QMI.  QMI is a generic
>> messaging protocol, and is not strictly limited to the unique operations
>> of a modem.
>>
>> Another usecase would be Sahara - a custom file transfer protocol used
>> for uploading firmware images, and downloading crashdumps.
> 
> Thanks, I was asking for use cases, not which proprietary vendor
> protocol you can implement over it.
> 
> None of the use cases you mention here should require a direct FW -
> user space backdoor for WLAN.

Uploading runtime firmware, with variations based on the runtime mode. 
Flashing the onboard flash based on cryptographic keys.  Accessing 
configuration data.  Accessing device logs.  Configuring device logs. 
Synchronizing the device time reference to Linux local or remote time 
sources.  Enabling debugging/performance hardware.  Getting software 
diagnostic events.  Configuring redundancy hardware per workload. 
Uploading new cryptographic keys.  Invalidating cryptographic keys. 
Uploading factory test data and running factory tests.

Need more?

-- 
Jeffrey Hugo
Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ