OpenBSD Journal

p2k18 Hackathon Report: Landry Breuil on USB, pledging firefox, and much more

Contributed by rueda on from the not-real-kernel-hacking dept.

Landry Breuil (landry@) has an extensive report for our readers:

I came to this hackathon with vague plans to play with WebRTC and firefox (i had brought an external Logitech Orbit webcam that weerd@ sent me ages ago and a headset/mic) and nothing more … and it proved out to be the right plan, as i was way more productive than i expected !

First, i gave up on the original plan of coming by train because of the strikes, and had realized denis@ was also coming to this hackathon and we live near the same city - which allowed us to carpool, and allowed me to learn many things about running your own ISP, and how to build your own fiber network :)

We managed to reach Nantes in 6h and i went straight into testing mode with my webcam… only to realize it only worked on my x200s, and not on this shiny x1 5th gen which had usb3. Good thing that mpi@ was here, as we quickly figured out usb3 was the issue here, and that disabling it in the bios allowed both the internal x1 webcam (which was supposedly broken, triggering "uvideo0: could not open VS pipe: INVAL" messages in syslog) and the external one to fully work. Win!

The only sad thing being that video(1) itself doesn't work live with recent hardware, as it doesnt support the Xv encodings provided by the modesetting(4) driver to directly display frames on the screen, but my webcams both worked in firefox !

This xhci/usb3 problem being looked at by mpi@, i started playing with the mic recording again, then trying to see each other's webcams with gilles@, then actually chatting over the network, but it turned out everything was just working. Boring. Just try to use WebRTC for audio/video chat, it should just work in firefox 59 on 6.3… just make sure you allow your own user to access /dev/video0! (This permission issue is being currently discussed, as there's no perfect way to make it user-friendly while satisfying the paranoids…)

Since i had two webcams, i saw that the permission popup in Firefox ('Do you want to allow firefox to share this mic/webcam ?') was showing two dummy "Generic USB video class device" in the selector, with no way to figure out which one was which one… after a quick chat with our USB master mpi@, i figured how it could be improved (ie use the actual USB product name) in the uvideo(4) driver, and the fix was quickly committed.

On the side, to change a bit from working on firefox i did the usual updates for various ports, this time giving a bit of love to the mpd/mpc gang, and the influxdb/collectd/grafana/facette stack - this stuff was somewhat easy, as was the nginx 1.14 update: even if it's a new stable branch, config didn't change and it's just running flawlessly in production.

I also wanted since some months to update our freerdp/remmina ports, as semarie@ had sent an update back in january that wasn't ready for commit yet - after a bit more of testing in various situations (thanks denis@, jasper@ and giovanni@ for the tests, and shodan.io for providing open vnc/rdp servers ;-) it was deemed ready for the tree.

Being at the same table as eric@ and gilles@, i overheard lots of chat about the new config grammar they wanted to polish to make way for the filters, and got lots of valuable information from gilles@ about the ways OpenSMTPD could be (ab)used :)

mpi@ being not far away, i also learnt many things about the USB stack, and he showed me one of his annoyances that he'd like to see fixed: the devices were queried several times for the vendor/product/serial informations, which wouldn't actually changed, but unnecessarily generated USB control traffic that could disturb the regular USB access. Me, diving in the kernel USB stack ? You must be kidding me… well, after all, it's only C code, trying to understand what calls what in what order, move things around… so i managed to wrap up something that actually seemed better, then went on to test it with several types of devices, from bsd, from bsd.rd… you don't want to fuck up something and create regressions, right ? The diff is now committed as i finally built enough confidence into my own modifications. Sadly, i didn't manage to fix the axe(4) that i brought, so i'm not yet a real kernel hacker :)

After this kernel diving, i was ready for something that had been on my plate for a year or so, with me always pushing it later in front of the ginormous task: adding pledge(2) to firefox! This turned out to be not that hard in the end, first trying to understand how the existing sandboxing code worked in firefox, where it was called, for which process type, etc… then trying to build with the sandboxing code enabled, adding some initial pledges, hoisting some unnedded lowlevel system calls…

As it takes two to three hours to build it, i didn't want to go the full cycle for each of my tries, so i devised a way to make pledge strings configurable at runtime via about:config knobs, which also proved the right way to quickly figure out the right 'default' pledge set needed for full operation of the main process and the content processes. Of course, this will only be for a testing period, in the end the pledges will probably be hardcoded to a safe subset. I initiated discussion with upstream to figure out the right way to integrate it directly there, as usual.

The actual result of this work is (as always) available in my git tree, based off the beta branch for firefox 60, and my plan so far is to commit the pledge patchset when 60 hits release in the coming weeks, so that it gets wider testing: so far, only some people in the hackroom (thanks kn@) gave me valuable feedback on it, and it definitely needs more dogfooding for all the possible use cases. Ppl, i even provide packages!

On the last evening, i played a bit with the just-imported upt tool that danj@ had ported, so that i could quickly wrap up ports for the dozens of missing dependencies for synapse, the python-based matrix reference server that you can selfhost. It's still a bit rough around the edges, but i posted my WIP to ports@ in the hope that some people might be interested in it. I might look at it again in the future…

This being a hackathon week, there was of course the very important back and forth with other developers, discussion about large changes, reviewing of diffs floating around, testing other's patches, meeting new developers in person (welcome kn@ and solene@!) - this is what makes such events priceless…

And on top of that the social aspect of going for beers & restaurants, eating waaaay too much, laughing about a lot of silly things, relaxing with table tennis, getting destroyed by jca@ at table football… because sometimes, it's vital to take some time off from hacking :)

Hats off to gilles@ and the OpenBSD Foundation for making this happen again!

Thanks, Landry, for great report!

(Comments are closed)


Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]