netdev - Re: [PATCH net-next 1/1] net: wwan: t7xx: Add port for modem logging

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: <b9cc320f-12b1-7460-5591-4ddc8b7f417f@linux.intel.com>
Date:   Mon, 23 May 2022 22:11:00 -0700
From:   "moises.veleta" <moises.veleta@...ux.intel.com>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     netdev@...r.kernel.org, davem@...emloft.net,
        johannes@...solutions.net, ryazanov.s.a@...il.com,
        loic.poulain@...aro.org, m.chetan.kumar@...el.com,
        chandrashekar.devegowda@...el.com, linuxwwan@...el.com,
        haijun.liu@...iatek.com, andriy.shevchenko@...ux.intel.com,
        ilpo.jarvinen@...ux.intel.com, ricardo.martinez@...ux.intel.com,
        sreehari.kancharla@...el.com, dinesh.sharma@...el.com
Subject: Re: [PATCH net-next 1/1] net: wwan: t7xx: Add port for modem logging


On 5/20/22 15:00, moises.veleta wrote:
>
> On 5/20/22 14:46, Jakub Kicinski wrote:
>> On Fri, 20 May 2022 12:16:19 -0700 moises.veleta wrote:
>>> On 5/20/22 11:15, Jakub Kicinski wrote:
>>>> On Fri, 20 May 2022 11:01:31 -0700 moises.veleta wrote:
>>>>> On 5/20/22 10:48, Jakub Kicinski wrote:
>>>>>> On Fri, 20 May 2022 10:42:56 -0700 moises.veleta wrote:
>>>>>>> Can we use debugfs to send an "on" or "off" commands, wherein 
>>>>>>> the driver
>>>>>>> then sends special command sequences to the the firmware 
>>>>>>> triggering the
>>>>>>> modem logging on and off?
>>>>>> On/off for all logging or for particular types of messages?
>>>>>> If it's for all logging can't the act of opening the debugfs
>>>>>> file be used as on "on" signal and closing as "off"?
>>>>>>
>>>>>> Where do the logging messages go?
>>>>> It would be "on/off" for all logging.
>>>>> Yes, opening the debugfs file can be used for "on" and closing for 
>>>>> "off"
>>>>> without needing to use copy_from_user.
>>>> Sounds good. Can we also divert the actual logs so that they can be
>>>> read out of that debugfs file? That'd feel most natural to me..
>>>>
>>>>> Logging messages would go to the relay interface file for 
>>>>> consumption by
>>>>> a user application.
>>>> What's the relay interface? a special netdev? chardev? tty?
>>>>
>>> The relay interface is a 'relay channel' where a userspace applications
>>> can read from and retrieve data as it becomes available. The driver
>>> would relay modem logs to this created channel file.
>>>
>>> https://www.kernel.org/doc/html/latest/filesystems/relay.html
>> The API for this thing seems confusing, does it not give the kernel
>> side any signal that user space has attached / shown interest in the
>> data?
>>
>> If not a simple debugfs file which only accepts on/off or 0/1 SGTM.
>
> For modem logging, the driver is relaying the logs (a large amount 
> varying on modem traffic) to the relay interface file that will be 
> overwritten if not consumed. It does not care if the user application 
> is reading them or not. That is up to the user application to read and 
> process.
>
> The IOSM driver in WWAN uses this relay interface & debugfs 
> combination, in a similar fashion, please see "iosm_ipc_trace.c" for 
> their implementation. Should have mentioned that earlier, pardon the 
> terseness.
>
Is the issue with using the debugfs to send random data to the modem an 
issue with validation?
If so, what if the modem itself is validating the input string would 
that suffice to allow this debugfs control port to act as the medium 
between user space applications and the modem? Leaving the driver blind 
to that process.
Or is it preferable to have the driver do the validation on the user 
space input to the modem?