[Bug 297669] Defects in TTY IOCTLs in Linux Emulation

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=297669

            Bug ID: 297669
           Summary: Defects in TTY IOCTLs in Linux Emulation
           Product: Base System
           Version: 15.1-RELEASE
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: misc
          Assignee: [email protected]
          Reporter: [email protected]

I have been trying to work with some serial devices in linuxulator. In the
process, I have discovered a few discrepancies in how Linuxulator translates
TTY-related IOCTLs, as well as cause of a panic.

This affects some existing applications: cutecom, minicom, etc. have sporadic
functionality under a linux chroot depending on the specific speeds selected.




The linux kernel checks for provision of the BOTHER flag, as the
[linuxulator](https://github.com/freebsd/freebsd-src/blob/a6e9e4cb259c3394aab4dc3e407d932866a02884/sys/compat/linux/linux_ioctl.c#L670)
source does. However, linux [also looks for
zero](https://github.com/torvalds/linux/blob/v6.19/drivers/tty/tty_baudrate.c#L92)
as a special case. When the input section of the baud speed is zero, the input
speed is taken to be the same as the output speed, offering a less verbose if
more complicated way of setting the two.



More detailed notes are available in a good guide
[here](https://github.com/npat-efault/picocom/blob/master/termios2.txt)


From googling, it seems this practice is quite prevalent amongst various serial
packages and self-standing repositories, and commonly-mentioned on stack
overflow. For example, this approach is used by [Qt's serial
library](https://github.com/qt/qtserialport/blob/v6.11.0/src/serialport/qserialport_unix.cpp#L610)

I believe Linuxulator should therefore implement this check for feature parity.


Also, the  speed table
(https://github.com/freebsd/freebsd-src/blob/a6e9e4cb259c3394aab4dc3e407d932866a02884/sys/compat/linux/linux_ioctl.c#L374)
is limited by bauds up to 115200; I understand there is some platform-dependent
branching in the Linux tree, but, higher speeds are available in current
kernels. Given that FreeBSD has the speed specified as a simple integer
natively, it would be good if this table could be extended further to support
higher hardcoded speeds. 



In addition to termios2, there is the serial header and set of syscalls. This
involves setting a custom divisor for the speed. I haven't investigated this
much yet, in part as it's more fiddly and I don't have the time right now as I
type, although the default settings I got back when calling TIOCGSERIAL had a
zero in the baud_base field. It looks from the sources the setter side is
currently unimplemented, so that makes sense, but I mention as in the process
of this project, a division by zero caused a panic in the USB COM
driver(#297668), and whilst I have now reproduced that outwith linux emulation
using native `tcsetattr`, a similar kind of error might come up if the divisor
is zero and manages to work its way through the system. I've seen a few
projects using this API as a way to set a custom speed, so it'd be good to
support it, but also there are quite a few ways some not-entirely-sensical
speeds could some in that may cause a similar panic.

Lastly, some other (slightly more) hacky methods have been specified in
[this](https://stackoverflow.com/a/19440269) StackOverflow reply; I have not
played with these yet, but there may be further corner cases that are not
currently handled.

Thanks!

-- 
You are receiving this mail because:
You are the assignee for the bug.