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-next>] [day] [month] [year] [list]
Message-ID: <AM4PR0301MB22282740FE8D06D8BB573F0583760@AM4PR0301MB2228.eurprd03.prod.outlook.com>
Date:   Thu, 23 Jul 2020 15:06:51 +0000
From:   Yannick Schinko <y.schinko@...nectingmedia.de>
To:     "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Interact with a serial device over USB

Hello,

so before I get into any detail I'd like to make clear that I am not at all familiar with the Linux kernel itself. However I'm not an inexperienced programmer.
Additionally the driver I'm describing here (and that I ultimately plan to create) is not intended to merged into the kernel itself. It's made for a specific piece of hardware that will only be produced in miniscule numbers. In turn that means removing existing modules to replace them with my own is a possibility.

Now, why I am writing here in the first place:
Currently the company I work for is designing an inline UPS for a very specific board (the APU2 series from PC engines). On that UPS there's a microcontroller that communicates over USB with the help of a CH341 chip.
I have already successfully implemented an userland program that communicates with the microcontroller. This works great! However there's two issues that led me to the conclusion that I need to implement this as a kernel module:
- Startup and shutdown times/timings: I noticed early on that the program starts too late on boot and stops too early on shutdown, no matter what I did (excluding very very dirty and impractical solutions that should never be used in any kind of production machine) I could not get it to start early enough and survive the shut down sequence long enough. The only way I can think of to circumvent this is by turning the program into a kernel module as that will allow it to start before the OS and to shutdown after the OS, which would be acceptable.
- Providing sensor data: The microcontroller has voltage sensors and temperature sensors that I would like to make available to userspace through the normal hwmon interfaces. According to my research that is only possible using a kernel module. Funnily enough that part is already implemented and works provided I feed it mocked data.

In consequence I need to create a kernel module (or at least I think so) that listens to data sent by the microcontroller over USB and then sends back some other information in response.
As a secondary functionality it would be amazing if I somehow could still forward that device as a tty (as it currently is) so I can flash firmware using avrdude. I was thinking that as long as nothing is using that tty in userspace, the kernel module listens to the device and sends responses but stops doing that as soon as the tty is in use and also continues listening again as soon as it's no longer in use. While this would be amazing to have it's not required for our use case.

I have looked into the source code for the CH341 driver and have also come across serdev. So I'm thinking of essentially modifying the CH341 driver for my purposes or using serdev to attach to the tty that's created by the CH341 driver itself.
However both are currently a fair bit beyond my understanding and frankly I have no idea how to proceed.

So anyone willing to help me out in this endeavor would be greatly appreciated!

Now the module is licensed under GPLv3 (from my understanding I'm allowed to do that if I'm modifying code licensed under GPLv2. If not, please let me know and I will change it ASAP) and the source is available at https://gitlab.connectingmedia.de/ServiceCockpit/APU-UPS-MicroController/-/tree/master/apusv_sensor if you are interested in it.

Should I have forgotten any important details, don't hesitate to ask.

Kind regards,
Yannick Schinko

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ