SMAP violation when attaching FTDI based serial device

[probono]

Kernel panic when attaching FTDI based serial device

KDL screenshot: ​https://i.imgur.com/GWMmSRA.jpg

Reproducible:

• Attach a FTDI based device (Arduino mini)
• Try to open the port with the SerialConnect tool

Disabling SMEP and SMAP in bootloader prevents this crash from happening.

[probono]

/> uname -a
Haiku shredder 1 hrev53259+3 Jul 15 2019 23:37:0 x86_64 x86_64 Haiku

[waddlesplash]

The return value of PrepareKernelAccess is not checked here: ​https://xref.plausible.coop/source/xref/haiku/src/add-ons/kernel/busses/usb/xhci.cpp#2804

However, it is very curious this appears as a "user mapped address"; I would expect InitKernelAccess to have made it into a kernel one (by subtracting off the area base). The syslog tail should show what is really happening.

[probono]

How can I get a syslog tail? To trigger the exception, I need to open the port in SerialConnect (which requires a mouse or keyboard, which I don't have while KDL is open). Once I have triggered the exception by opening the port, the USB keyboard becomes unresponsive so that I cannot type anything anymore in KDL.

[diver]

Try running /bin/kernel_debugger first and then exit from KDL with es.

[probono]

When I do that and then open the port in SerialConnect, KDL appears but I cannot enter anything.

[probono]

Maybe KDL should print the last 50 lines of syslog by default?

[diver]

Do you maybe have ps2 keyboard laying around? That should work in KDL.

[probono]

Unfortunately, I the machine does not have that port anymore, and I don't have a PS/2 keyboard around anymore.

[diver]

Maybe KDL can print last 50 lines of syslog after 1 minute timeout is not that bad after all?

[waddlesplash]

Doing that would be pretty difficult.

Actually I have an idea as to what might be going wrong here. The error message still doesn't make sense, but hopefully my hunch will be correct.

[waddlesplash]

hrev53280~1 may fix this, please test when you get a chance.

[waddlesplash]

Actually the real culprit seems to be this: ​https://github.com/haiku/haiku/blob/master/src/add-ons/kernel/drivers/ports/usb_serial/SerialDevice.cpp#L91

Since this create_area is called in the kernel, it will be mapped into the kernel address space but with user-writeable permissions; thus IS_USER_ADDRESS will return false and the USB stack will not use the user functions to access it.

AFAICT, it is not used outside this driver or passed to user-space, so the solution seems to be to simply change it to be mapped in the kernel only. PulkoMandy, can you confirm this is correct?

[pulkomandy]

The area is used for 3 tings:

• interrupt driver is passed to the USB module. You may know better than me what happens to this one
• output buffer is passed to the TTY module. I have no idea what happens there
• write buffer seems to be completely internal to the driver.

[probono]

Still getting this in hrev53259+3. I don't know how to get hrev53280~1. It is not offered to me, pkgman update thinks I am up to date.

[diver]

Package repos are not currently being generated automatically due to a switch to another CI. Anyboot images are being updated as before, thought.

[probono]

I see. Nightly repository was known to the system but not enabled. After enabling it and rebooting, I now have hrev53293. The issue persists, though.

[waddlesplash]

Fixed in hrev53309.

[nielx]

Assign tickets with status=closed and resolution=fixed within the R1/beta2 development window to the R1/beta2 Milestone