Re: [systemd-devel] Supporting U2F over HID on Linux?
On Tue, Dec 9, 2014 at 12:46 PM, Andy Lutomirski l...@amacapital.net wrote:
On Mon, Nov 3, 2014 at 12:41 PM, Andy Lutomirski l...@amacapital.net wrote:
On Mon, Nov 3, 2014 at 12:21 PM, Jiri Kosina jkos...@suse.cz wrote:
On Mon, 3 Nov 2014, David Herrmann wrote:
Agreed, mostly. My only real concern is that this could be annoying
for the userspace developers who will need to target Linux and HIDAPI
separately. Admittedly the Linux support will be trivial.
I see. I'll not stop you from using hidraw, I'd just not recommend it.
Especially for security stuff I dislike exposing the whole HID device
writable. But yeah, I guess you got my point.
Alright, I am basically thinking loudly now, but how about we allow HID
drivers that would override default hidraw interface?
I am very well aware of the fact that this could be opening a can of
worms, so we'll have to make it very restrictive. How about, let's say, we
allow HID drivers to provide custom hidraw interface (completely
overriding the one that HID core would normally create) only for cases
such as:
- the intent is to expose only certain parts of a combined device
- the intent is to introduce some level of access control
I.e. still no interference of kernel with data parsing allowed.
Hmm. Would this be like a filter on hidraw actions?
How would udev distinguish these special hidraw devices from normal
hidraw devices?
Also, for U2F, this could be a little awkward. There's some crazy
fragmentation stuff to allow a U2F request to be split across HID
requests, and I think a kernel driver would much rather get the
original unfragmented application request.
I started writing a driver for this. I got enumeration working. I
assume I should create a u2f device class, and then... ?
Where am I supposed to get my character device from? Do I register my
own chrdev major? Do I use misc? Is there some input thing I'm
supposed to use?
Another question:
I'm hitting this in hid_input_report:
if (down_trylock(hid-driver_input_lock)) {
pr_err(HID: trylock failed\n); // I added this
return -EBUSY;
}
This is a problem for u2f: u2f reports are actual protocol messages,
and there isn't a retransmit mechanism. Losing messages randomly
causes the handshake to fail, and then nothing works.
I *think* that the only way I can hit that failure is during probe (or
if the USB stack somehow completes two transfers at once). This still
makes it quite awkward to start IO from the probe routine.
I could start a work item to take driver_input_lock, release it again,
and then start the handshake, but that sucks.
Ideas?
--Andy
Thanks,
Andy
--Andy
I can give the driver a try. It'll actually be simpler than the spec
makes it out, since a real kernel driver will have no need to
arbitrate with itself.
I'll gladly review any custom HID drivers. Feel free to put me on CC
when sending to linux-input. There's also a lot of examples in
drivers/hid/ in case you need a head-start (especially if you need the
raw_event callback).
Same here, of course.
Please always CC me in parallel to sending to linux-input@ to make sure
that the patch doesn't fall in between cracks.
Thanks,
--
Jiri Kosina
SUSE Labs
--
Andy Lutomirski
AMA Capital Management, LLC
--
Andy Lutomirski
AMA Capital Management, LLC
--
Andy Lutomirski
AMA Capital Management, LLC
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Supporting U2F over HID on Linux?
On Mon, Nov 3, 2014 at 12:41 PM, Andy Lutomirski l...@amacapital.net wrote: On Mon, Nov 3, 2014 at 12:21 PM, Jiri Kosina jkos...@suse.cz wrote: On Mon, 3 Nov 2014, David Herrmann wrote: Agreed, mostly. My only real concern is that this could be annoying for the userspace developers who will need to target Linux and HIDAPI separately. Admittedly the Linux support will be trivial. I see. I'll not stop you from using hidraw, I'd just not recommend it. Especially for security stuff I dislike exposing the whole HID device writable. But yeah, I guess you got my point. Alright, I am basically thinking loudly now, but how about we allow HID drivers that would override default hidraw interface? I am very well aware of the fact that this could be opening a can of worms, so we'll have to make it very restrictive. How about, let's say, we allow HID drivers to provide custom hidraw interface (completely overriding the one that HID core would normally create) only for cases such as: - the intent is to expose only certain parts of a combined device - the intent is to introduce some level of access control I.e. still no interference of kernel with data parsing allowed. Hmm. Would this be like a filter on hidraw actions? How would udev distinguish these special hidraw devices from normal hidraw devices? Also, for U2F, this could be a little awkward. There's some crazy fragmentation stuff to allow a U2F request to be split across HID requests, and I think a kernel driver would much rather get the original unfragmented application request. I started writing a driver for this. I got enumeration working. I assume I should create a u2f device class, and then... ? Where am I supposed to get my character device from? Do I register my own chrdev major? Do I use misc? Is there some input thing I'm supposed to use? Thanks, Andy --Andy I can give the driver a try. It'll actually be simpler than the spec makes it out, since a real kernel driver will have no need to arbitrate with itself. I'll gladly review any custom HID drivers. Feel free to put me on CC when sending to linux-input. There's also a lot of examples in drivers/hid/ in case you need a head-start (especially if you need the raw_event callback). Same here, of course. Please always CC me in parallel to sending to linux-input@ to make sure that the patch doesn't fall in between cracks. Thanks, -- Jiri Kosina SUSE Labs -- Andy Lutomirski AMA Capital Management, LLC -- Andy Lutomirski AMA Capital Management, LLC ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Supporting U2F over HID on Linux?
Hi On Sun, Nov 2, 2014 at 7:57 PM, Andy Lutomirski l...@amacapital.net wrote: I want to get U2F (universal second factor, sometimes called security key or even gnubby) working on Linux. U2F tokens are HID devices that speak a custom protocol. The intent is that user code will speak to then using something like HIDAPI. The trick is that, for HIDAPI to work, something needs to recognize these devices and get udev to set appropriate device permissions. [snip] - An actual kernel driver for U2F devices using the hid group mechanism for enumeration. This seems overcomplicated. Imho, this is the way to go. Create a proper char-dev for U2F, create an API and make it work. We had this discussion earlier about vendor-extensions that should be writable via hidraw from user-space. This turned out to be really messy.. and was discussed for several weeks straight. hidraw just wasn't designed as unprivileged user-space API. For instance, what happens if a device provides U2F plus something else? Both will be on the same hidraw device. We could split hidraw per usage, but I don't see how that is superior to a proper U2F API. And once one usage can affect a device as a whole (like power-off), you're screwed. Just look at the libusb mess where some devices are handled in the kernel and some in user-space (eg., see Gnome cheese, media devices, ...). I don't think we should repeat that with HID. Thanks David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Supporting U2F over HID on Linux?
On Mon, Nov 3, 2014 at 11:03 AM, David Herrmann dh.herrm...@gmail.com wrote: Hi On Sun, Nov 2, 2014 at 7:57 PM, Andy Lutomirski l...@amacapital.net wrote: I want to get U2F (universal second factor, sometimes called security key or even gnubby) working on Linux. U2F tokens are HID devices that speak a custom protocol. The intent is that user code will speak to then using something like HIDAPI. The trick is that, for HIDAPI to work, something needs to recognize these devices and get udev to set appropriate device permissions. [snip] - An actual kernel driver for U2F devices using the hid group mechanism for enumeration. This seems overcomplicated. Imho, this is the way to go. Create a proper char-dev for U2F, create an API and make it work. We had this discussion earlier about vendor-extensions that should be writable via hidraw from user-space. This turned out to be really messy.. and was discussed for several weeks straight. hidraw just wasn't designed as unprivileged user-space API. For instance, what happens if a device provides U2F plus something else? Both will be on the same hidraw device. We could split hidraw per usage, but I don't see how that is superior to a proper U2F API. And once one usage can affect a device as a whole (like power-off), you're screwed. Agreed, mostly. My only real concern is that this could be annoying for the userspace developers who will need to target Linux and HIDAPI separately. Admittedly the Linux support will be trivial. I can give the driver a try. It'll actually be simpler than the spec makes it out, since a real kernel driver will have no need to arbitrate with itself. --Andy Just look at the libusb mess where some devices are handled in the kernel and some in user-space (eg., see Gnome cheese, media devices, ...). I don't think we should repeat that with HID. Thanks David -- Andy Lutomirski AMA Capital Management, LLC ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Supporting U2F over HID on Linux?
Hi On Mon, Nov 3, 2014 at 8:19 PM, Andy Lutomirski l...@amacapital.net wrote: On Mon, Nov 3, 2014 at 11:03 AM, David Herrmann dh.herrm...@gmail.com wrote: Hi On Sun, Nov 2, 2014 at 7:57 PM, Andy Lutomirski l...@amacapital.net wrote: I want to get U2F (universal second factor, sometimes called security key or even gnubby) working on Linux. U2F tokens are HID devices that speak a custom protocol. The intent is that user code will speak to then using something like HIDAPI. The trick is that, for HIDAPI to work, something needs to recognize these devices and get udev to set appropriate device permissions. [snip] - An actual kernel driver for U2F devices using the hid group mechanism for enumeration. This seems overcomplicated. Imho, this is the way to go. Create a proper char-dev for U2F, create an API and make it work. We had this discussion earlier about vendor-extensions that should be writable via hidraw from user-space. This turned out to be really messy.. and was discussed for several weeks straight. hidraw just wasn't designed as unprivileged user-space API. For instance, what happens if a device provides U2F plus something else? Both will be on the same hidraw device. We could split hidraw per usage, but I don't see how that is superior to a proper U2F API. And once one usage can affect a device as a whole (like power-off), you're screwed. Agreed, mostly. My only real concern is that this could be annoying for the userspace developers who will need to target Linux and HIDAPI separately. Admittedly the Linux support will be trivial. I see. I'll not stop you from using hidraw, I'd just not recommend it. Especially for security stuff I dislike exposing the whole HID device writable. But yeah, I guess you got my point. I can give the driver a try. It'll actually be simpler than the spec makes it out, since a real kernel driver will have no need to arbitrate with itself. I'll gladly review any custom HID drivers. Feel free to put me on CC when sending to linux-input. There's also a lot of examples in drivers/hid/ in case you need a head-start (especially if you need the raw_event callback). Thanks David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Supporting U2F over HID on Linux?
On Mon, 3 Nov 2014, David Herrmann wrote: Agreed, mostly. My only real concern is that this could be annoying for the userspace developers who will need to target Linux and HIDAPI separately. Admittedly the Linux support will be trivial. I see. I'll not stop you from using hidraw, I'd just not recommend it. Especially for security stuff I dislike exposing the whole HID device writable. But yeah, I guess you got my point. Alright, I am basically thinking loudly now, but how about we allow HID drivers that would override default hidraw interface? I am very well aware of the fact that this could be opening a can of worms, so we'll have to make it very restrictive. How about, let's say, we allow HID drivers to provide custom hidraw interface (completely overriding the one that HID core would normally create) only for cases such as: - the intent is to expose only certain parts of a combined device - the intent is to introduce some level of access control I.e. still no interference of kernel with data parsing allowed. I can give the driver a try. It'll actually be simpler than the spec makes it out, since a real kernel driver will have no need to arbitrate with itself. I'll gladly review any custom HID drivers. Feel free to put me on CC when sending to linux-input. There's also a lot of examples in drivers/hid/ in case you need a head-start (especially if you need the raw_event callback). Same here, of course. Please always CC me in parallel to sending to linux-input@ to make sure that the patch doesn't fall in between cracks. Thanks, -- Jiri Kosina SUSE Labs ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Supporting U2F over HID on Linux?
On Mon, Nov 3, 2014 at 12:21 PM, Jiri Kosina jkos...@suse.cz wrote: On Mon, 3 Nov 2014, David Herrmann wrote: Agreed, mostly. My only real concern is that this could be annoying for the userspace developers who will need to target Linux and HIDAPI separately. Admittedly the Linux support will be trivial. I see. I'll not stop you from using hidraw, I'd just not recommend it. Especially for security stuff I dislike exposing the whole HID device writable. But yeah, I guess you got my point. Alright, I am basically thinking loudly now, but how about we allow HID drivers that would override default hidraw interface? I am very well aware of the fact that this could be opening a can of worms, so we'll have to make it very restrictive. How about, let's say, we allow HID drivers to provide custom hidraw interface (completely overriding the one that HID core would normally create) only for cases such as: - the intent is to expose only certain parts of a combined device - the intent is to introduce some level of access control I.e. still no interference of kernel with data parsing allowed. Hmm. Would this be like a filter on hidraw actions? How would udev distinguish these special hidraw devices from normal hidraw devices? Also, for U2F, this could be a little awkward. There's some crazy fragmentation stuff to allow a U2F request to be split across HID requests, and I think a kernel driver would much rather get the original unfragmented application request. --Andy I can give the driver a try. It'll actually be simpler than the spec makes it out, since a real kernel driver will have no need to arbitrate with itself. I'll gladly review any custom HID drivers. Feel free to put me on CC when sending to linux-input. There's also a lot of examples in drivers/hid/ in case you need a head-start (especially if you need the raw_event callback). Same here, of course. Please always CC me in parallel to sending to linux-input@ to make sure that the patch doesn't fall in between cracks. Thanks, -- Jiri Kosina SUSE Labs -- Andy Lutomirski AMA Capital Management, LLC ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Supporting U2F over HID on Linux?
On Sun, 2 Nov 2014, Andy Lutomirski wrote: I want to get U2F (universal second factor, sometimes called security key or even gnubby) working on Linux. U2F tokens are HID devices that speak a custom protocol. The intent is that user code will speak to then using something like HIDAPI. The trick is that, for HIDAPI to work, something needs to recognize these devices and get udev to set appropriate device permissions. Just to make sure we are on the same page -- this is really only about setting proper device node permissions and nothing else, right? My question is: how should this be done? The official way to enumerate U2F devices is to look for a HID usage page 0xf1d0 containing usage 0x1. Options include: - A builtin udev helper that reads the sysfs report_descriptor for hid or hidraw devices and sets attributes accordingly (either ID_SECURITY_TOKEN or something more general). Hmmm ... please keep in mind that report_descriptor is actually in debugfs, so it's a bit questionable whether you can rely on it being present on well-defined location on all systems. You can get it from different other places though, such as libusb (but then you are limited only to USB HID devices ... which might be enough in your particular case). - A udev helper that does this and doesn't live in the systemd tree. I don't love this option -- I'd prefer for this to be as plug-and-play as possible. Agreed. - HID core code in the kernel to add HID_USAGES=f1d1:lots:of:other:things to the uevent (or udev code to do the same). This might end up producing a rather long string or some devices. We have been thinking about this quite a lot in the past, and decided to postpone this until there is a very good reason for it to happen. - An actual kernel driver for U2F devices using the hid group mechanism for enumeration. This seems overcomplicated. Hmmm ... why do you think so? I believe it actually should be really super-trivial. Thanks, -- Jiri Kosina SUSE Labs ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Supporting U2F over HID on Linux?
Hi Andy, On Sun, Nov 2, 2014 at 7:57 PM, Andy Lutomirski l...@amacapital.net wrote: I want to get U2F (universal second factor, sometimes called security key or even gnubby) working on Linux. U2F tokens are HID devices that speak a custom protocol. The intent is that user code will speak to then using something like HIDAPI. The trick is that, for HIDAPI to work, something needs to recognize these devices and get udev to set appropriate device permissions. My question is: how should this be done? The official way to enumerate U2F devices is to look for a HID usage page 0xf1d0 containing usage 0x1. Options include: - A builtin udev helper that reads the sysfs report_descriptor for hid or hidraw devices and sets attributes accordingly (either ID_SECURITY_TOKEN or something more general). I don't think we should have such special-purpose logic in the udev core. [...] - HID core code in the kernel to add HID_USAGES=f1d1:lots:of:other:things to the uevent (or udev code to do the same). This might end up producing a rather long string or some devices. This makes the most sense to me. We could put this logic (adapting the patch you posted) in src/udev/udev-builtin-usb_id.c. I'll comment on the patch separately. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Supporting U2F over HID on Linux?
On Sun, Nov 2, 2014 at 12:42 PM, Jiri Kosina jkos...@suse.cz wrote: On Sun, 2 Nov 2014, Andy Lutomirski wrote: I want to get U2F (universal second factor, sometimes called security key or even gnubby) working on Linux. U2F tokens are HID devices that speak a custom protocol. The intent is that user code will speak to then using something like HIDAPI. The trick is that, for HIDAPI to work, something needs to recognize these devices and get udev to set appropriate device permissions. Just to make sure we are on the same page -- this is really only about setting proper device node permissions and nothing else, right? Yes. My question is: how should this be done? The official way to enumerate U2F devices is to look for a HID usage page 0xf1d0 containing usage 0x1. Options include: - A builtin udev helper that reads the sysfs report_descriptor for hid or hidraw devices and sets attributes accordingly (either ID_SECURITY_TOKEN or something more general). Hmmm ... please keep in mind that report_descriptor is actually in debugfs, so it's a bit questionable whether you can rely on it being present on well-defined location on all systems. Huh? I have /sys/devices/pci:00/:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0/0003:1050:0120.0013/report_descriptor on my system. You can get it from different other places though, such as libusb (but then you are limited only to USB HID devices ... which might be enough in your particular case). I have no idea whether there will ever be a bluetooth U2F device. - A udev helper that does this and doesn't live in the systemd tree. I don't love this option -- I'd prefer for this to be as plug-and-play as possible. Agreed. - HID core code in the kernel to add HID_USAGES=f1d1:lots:of:other:things to the uevent (or udev code to do the same). This might end up producing a rather long string or some devices. We have been thinking about this quite a lot in the past, and decided to postpone this until there is a very good reason for it to happen. I'm not sure that U2F counts as a very good reason. - An actual kernel driver for U2F devices using the hid group mechanism for enumeration. This seems overcomplicated. Hmmm ... why do you think so? I believe it actually should be really super-trivial. The HID group part is trivial, but what interface would the driver expose? I don't think that a udev rule for hidraw matching the modalias makes any sense, and, if it were a real driver, what interface would it expose? Most cross-platform userspace code for U2F is likely to use HIDAPI. Admittedly, a U2F driver in the kernel would be slightly nicer from a multiplexing standpoint than hidraw. --Andy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Supporting U2F over HID on Linux?
On Sun, Nov 2, 2014 at 12:47 PM, Tom Gundersen t...@jklm.no wrote: Hi Andy, On Sun, Nov 2, 2014 at 7:57 PM, Andy Lutomirski l...@amacapital.net wrote: I want to get U2F (universal second factor, sometimes called security key or even gnubby) working on Linux. U2F tokens are HID devices that speak a custom protocol. The intent is that user code will speak to then using something like HIDAPI. The trick is that, for HIDAPI to work, something needs to recognize these devices and get udev to set appropriate device permissions. My question is: how should this be done? The official way to enumerate U2F devices is to look for a HID usage page 0xf1d0 containing usage 0x1. Options include: - A builtin udev helper that reads the sysfs report_descriptor for hid or hidraw devices and sets attributes accordingly (either ID_SECURITY_TOKEN or something more general). I don't think we should have such special-purpose logic in the udev core. [...] - HID core code in the kernel to add HID_USAGES=f1d1:lots:of:other:things to the uevent (or udev code to do the same). This might end up producing a rather long string or some devices. This makes the most sense to me. We could put this logic (adapting the patch you posted) in src/udev/udev-builtin-usb_id.c. How would that work? Can't a USB device have more than one HID class device under it? I could imagine a future U2F keyboard that has a HID class device for the keyboard part and another one for U2F. --Andy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Supporting U2F over HID on Linux?
On Sun, 2 Nov 2014, Andy Lutomirski wrote: Hmmm ... please keep in mind that report_descriptor is actually in debugfs, so it's a bit questionable whether you can rely on it being present on well-defined location on all systems. Huh? I have /sys/devices/pci:00/:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0/0003:1050:0120.0013/report_descriptor on my system. Brainfart on my side. We have 'rdesc' and 'events' in debugfs sice a long time, but then 'report_descriptor' has been added as a proper sysfs attribute some time around 3.0. - HID core code in the kernel to add HID_USAGES=f1d1:lots:of:other:things to the uevent (or udev code to do the same). This might end up producing a rather long string or some devices. We have been thinking about this quite a lot in the past, and decided to postpone this until there is a very good reason for it to happen. I'm not sure that U2F counts as a very good reason. It might well be the justifying reason. I'd first like to see what other options we have though. - An actual kernel driver for U2F devices using the hid group mechanism for enumeration. This seems overcomplicated. Hmmm ... why do you think so? I believe it actually should be really super-trivial. The HID group part is trivial, but what interface would the driver expose? I don't think that a udev rule for hidraw matching the modalias makes any sense, and, if it were a real driver, what interface would it expose? Most cross-platform userspace code for U2F is likely to use HIDAPI. Admittedly, a U2F driver in the kernel would be slightly nicer from a multiplexing standpoint than hidraw. Alternatively, you can just write udev rule which triggers on HID devices, issues HIDIOCGRDESC ioctl() on the just-created hidraw node, and decides afterwards whether node permissions need to be altered ... right? Thanks, -- Jiri Kosina SUSE Labs ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Supporting U2F over HID on Linux?
On Sun, 2 Nov 2014, Jiri Kosina wrote: Alternatively, you can just write udev rule which triggers on HID devices, issues HIDIOCGRDESC ioctl() on the just-created hidraw node, and decides afterwards whether node permissions need to be altered ... right? Just to make myself clear here -- this is basically alternative to your 1st option, but for cases where you want to make yourself independent on sysfs existence (I don't what is the craziness level of setups you are considering). -- Jiri Kosina SUSE Labs ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Supporting U2F over HID on Linux?
On Sun, Nov 2, 2014 at 10:13 PM, Andy Lutomirski l...@amacapital.net wrote: On Sun, Nov 2, 2014 at 12:47 PM, Tom Gundersen t...@jklm.no wrote: Hi Andy, On Sun, Nov 2, 2014 at 7:57 PM, Andy Lutomirski l...@amacapital.net wrote: I want to get U2F (universal second factor, sometimes called security key or even gnubby) working on Linux. U2F tokens are HID devices that speak a custom protocol. The intent is that user code will speak to then using something like HIDAPI. The trick is that, for HIDAPI to work, something needs to recognize these devices and get udev to set appropriate device permissions. My question is: how should this be done? The official way to enumerate U2F devices is to look for a HID usage page 0xf1d0 containing usage 0x1. Options include: - A builtin udev helper that reads the sysfs report_descriptor for hid or hidraw devices and sets attributes accordingly (either ID_SECURITY_TOKEN or something more general). I don't think we should have such special-purpose logic in the udev core. [...] - HID core code in the kernel to add HID_USAGES=f1d1:lots:of:other:things to the uevent (or udev code to do the same). This might end up producing a rather long string or some devices. This makes the most sense to me. We could put this logic (adapting the patch you posted) in src/udev/udev-builtin-usb_id.c. How would that work? Can't a USB device have more than one HID class device under it? I could imagine a future U2F keyboard that has a HID class device for the keyboard part and another one for U2F. Right, a separate built-in makes more sense then. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Supporting U2F over HID on Linux?
On Sun, Nov 2, 2014 at 2:45 PM, Benjamin Tissoires benjamin.tissoi...@gmail.com wrote: On Sun, Nov 2, 2014 at 4:40 PM, Jiri Kosina jkos...@suse.cz wrote: On Sun, 2 Nov 2014, Jiri Kosina wrote: Alternatively, you can just write udev rule which triggers on HID devices, issues HIDIOCGRDESC ioctl() on the just-created hidraw node, and decides afterwards whether node permissions need to be altered ... right? Just to make myself clear here -- this is basically alternative to your 1st option, but for cases where you want to make yourself independent on sysfs existence (I don't what is the craziness level of setups you are considering). I am a little bit concerned with the user space retrieving the descriptor, parsing it and then deciding how to set the permissions. It's not that it is super complex, but it will duplicate the parsing we already do in the kernel. Wacom tried to do that in their usb driver, and they never managed to fully implement one. I think the HID_GROUP solution is super trivial: - add a match on the U2F input report and set the group to HID_GROUP_U2F (2 lines in hid_scan_input_usage() in hid-core.c) - allow hid-generic to also match HID_GROUP_U2F (1 line in hid-generic.c). Then, the udev rule would be super trivial. I'm confused. What would the user-visible effect of this be? Would the hidraw node still show up? What is user code supposed to match to detect a U2F device or to otherwise set permissions? --Andy Also, if we want to further extend the kernel API for U2F, the group will already be in place. Cheers, Benjamin -- Andy Lutomirski AMA Capital Management, LLC ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Supporting U2F over HID on Linux?
On Sun, Nov 2, 2014 at 5:49 PM, Andy Lutomirski l...@amacapital.net wrote: On Sun, Nov 2, 2014 at 2:45 PM, Benjamin Tissoires benjamin.tissoi...@gmail.com wrote: On Sun, Nov 2, 2014 at 4:40 PM, Jiri Kosina jkos...@suse.cz wrote: On Sun, 2 Nov 2014, Jiri Kosina wrote: Alternatively, you can just write udev rule which triggers on HID devices, issues HIDIOCGRDESC ioctl() on the just-created hidraw node, and decides afterwards whether node permissions need to be altered ... right? Just to make myself clear here -- this is basically alternative to your 1st option, but for cases where you want to make yourself independent on sysfs existence (I don't what is the craziness level of setups you are considering). I am a little bit concerned with the user space retrieving the descriptor, parsing it and then deciding how to set the permissions. It's not that it is super complex, but it will duplicate the parsing we already do in the kernel. Wacom tried to do that in their usb driver, and they never managed to fully implement one. I think the HID_GROUP solution is super trivial: - add a match on the U2F input report and set the group to HID_GROUP_U2F (2 lines in hid_scan_input_usage() in hid-core.c) - allow hid-generic to also match HID_GROUP_U2F (1 line in hid-generic.c). Then, the udev rule would be super trivial. I'm confused. What would the user-visible effect of this be? Would the hidraw node still show up? What is user code supposed to match to detect a U2F device or to otherwise set permissions? The only change with what we currently have is that the modalias of the device will be something like MODALIAS=hid:b0003gHID_GROUP_U2Fvp. (replace HID_GROUP_U2F with the proper hex value). So matching against this modalias is trivial, and you can just put the hidraw node rw for users. The device will still be handled by hid-generic, so there will be no changes besides the modalias. So yes, you still need a udev rule to set the proper permission, but you will not have to parse the report descriptors. Cheers, Benjamin PS: some time spent and I realized that the modalias would be the one of the HID node, which the hidraw is a son. Not the hidraw node directly :/ --Andy Also, if we want to further extend the kernel API for U2F, the group will already be in place. Cheers, Benjamin -- Andy Lutomirski AMA Capital Management, LLC ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Supporting U2F over HID on Linux?
On Sun, Nov 2, 2014 at 3:01 PM, Benjamin Tissoires benjamin.tissoi...@gmail.com wrote: On Sun, Nov 2, 2014 at 5:49 PM, Andy Lutomirski l...@amacapital.net wrote: On Sun, Nov 2, 2014 at 2:45 PM, Benjamin Tissoires benjamin.tissoi...@gmail.com wrote: On Sun, Nov 2, 2014 at 4:40 PM, Jiri Kosina jkos...@suse.cz wrote: On Sun, 2 Nov 2014, Jiri Kosina wrote: Alternatively, you can just write udev rule which triggers on HID devices, issues HIDIOCGRDESC ioctl() on the just-created hidraw node, and decides afterwards whether node permissions need to be altered ... right? Just to make myself clear here -- this is basically alternative to your 1st option, but for cases where you want to make yourself independent on sysfs existence (I don't what is the craziness level of setups you are considering). I am a little bit concerned with the user space retrieving the descriptor, parsing it and then deciding how to set the permissions. It's not that it is super complex, but it will duplicate the parsing we already do in the kernel. Wacom tried to do that in their usb driver, and they never managed to fully implement one. I think the HID_GROUP solution is super trivial: - add a match on the U2F input report and set the group to HID_GROUP_U2F (2 lines in hid_scan_input_usage() in hid-core.c) - allow hid-generic to also match HID_GROUP_U2F (1 line in hid-generic.c). Then, the udev rule would be super trivial. I'm confused. What would the user-visible effect of this be? Would the hidraw node still show up? What is user code supposed to match to detect a U2F device or to otherwise set permissions? The only change with what we currently have is that the modalias of the device will be something like MODALIAS=hid:b0003gHID_GROUP_U2Fvp. (replace HID_GROUP_U2F with the proper hex value). So matching against this modalias is trivial, and you can just put the hidraw node rw for users. Do we really want udev matching against MODALIAS, and do we really want udev rules to hardcode hid group constants? I'd like this idea better if we added a HID_GROUP uevent property with a textual description, or perhaps something a little more specific. The hid group field seems to be used for different types of things. --Andy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Supporting U2F over HID on Linux?
On Sun, Nov 2, 2014 at 6:34 PM, Andy Lutomirski l...@amacapital.net wrote: On Sun, Nov 2, 2014 at 3:01 PM, Benjamin Tissoires benjamin.tissoi...@gmail.com wrote: On Sun, Nov 2, 2014 at 5:49 PM, Andy Lutomirski l...@amacapital.net wrote: On Sun, Nov 2, 2014 at 2:45 PM, Benjamin Tissoires benjamin.tissoi...@gmail.com wrote: On Sun, Nov 2, 2014 at 4:40 PM, Jiri Kosina jkos...@suse.cz wrote: On Sun, 2 Nov 2014, Jiri Kosina wrote: Alternatively, you can just write udev rule which triggers on HID devices, issues HIDIOCGRDESC ioctl() on the just-created hidraw node, and decides afterwards whether node permissions need to be altered ... right? Just to make myself clear here -- this is basically alternative to your 1st option, but for cases where you want to make yourself independent on sysfs existence (I don't what is the craziness level of setups you are considering). I am a little bit concerned with the user space retrieving the descriptor, parsing it and then deciding how to set the permissions. It's not that it is super complex, but it will duplicate the parsing we already do in the kernel. Wacom tried to do that in their usb driver, and they never managed to fully implement one. I think the HID_GROUP solution is super trivial: - add a match on the U2F input report and set the group to HID_GROUP_U2F (2 lines in hid_scan_input_usage() in hid-core.c) - allow hid-generic to also match HID_GROUP_U2F (1 line in hid-generic.c). Then, the udev rule would be super trivial. I'm confused. What would the user-visible effect of this be? Would the hidraw node still show up? What is user code supposed to match to detect a U2F device or to otherwise set permissions? The only change with what we currently have is that the modalias of the device will be something like MODALIAS=hid:b0003gHID_GROUP_U2Fvp. (replace HID_GROUP_U2F with the proper hex value). So matching against this modalias is trivial, and you can just put the hidraw node rw for users. Do we really want udev matching against MODALIAS, and do we really want udev rules to hardcode hid group constants? That's a good question. I don't think the hid group will change in the future and we can guarantee that in the kernel I think. I'd like this idea better if we added a HID_GROUP uevent property with a textual description, or perhaps something a little more specific. This refers back to Jiri's first remark. Adding such a thing is doable, but do we really want/need it :/ The hid group field seems to be used for different types of things. yes, my proposal is definitively a (ugly) hack around the groups which are used to select which hid subdriver we use. An other question which comes to my mind is don't we want logind to assign the hidraw node to the proper client? We may still need to tag the device somehow, but if logind prevents untrusted application to run arbitrary code on the u2f token, that might be a little bit safer than allowing anybody to read/write. Sorry to raise more questions than providing answers. Cheers, Benjamin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Supporting U2F over HID on Linux?
On Sun, Nov 2, 2014 at 4:40 PM, Benjamin Tissoires benjamin.tissoi...@gmail.com wrote: On Sun, Nov 2, 2014 at 6:34 PM, Andy Lutomirski l...@amacapital.net wrote: On Sun, Nov 2, 2014 at 3:01 PM, Benjamin Tissoires benjamin.tissoi...@gmail.com wrote: On Sun, Nov 2, 2014 at 5:49 PM, Andy Lutomirski l...@amacapital.net wrote: On Sun, Nov 2, 2014 at 2:45 PM, Benjamin Tissoires benjamin.tissoi...@gmail.com wrote: On Sun, Nov 2, 2014 at 4:40 PM, Jiri Kosina jkos...@suse.cz wrote: On Sun, 2 Nov 2014, Jiri Kosina wrote: Alternatively, you can just write udev rule which triggers on HID devices, issues HIDIOCGRDESC ioctl() on the just-created hidraw node, and decides afterwards whether node permissions need to be altered ... right? Just to make myself clear here -- this is basically alternative to your 1st option, but for cases where you want to make yourself independent on sysfs existence (I don't what is the craziness level of setups you are considering). I am a little bit concerned with the user space retrieving the descriptor, parsing it and then deciding how to set the permissions. It's not that it is super complex, but it will duplicate the parsing we already do in the kernel. Wacom tried to do that in their usb driver, and they never managed to fully implement one. I think the HID_GROUP solution is super trivial: - add a match on the U2F input report and set the group to HID_GROUP_U2F (2 lines in hid_scan_input_usage() in hid-core.c) - allow hid-generic to also match HID_GROUP_U2F (1 line in hid-generic.c). Then, the udev rule would be super trivial. I'm confused. What would the user-visible effect of this be? Would the hidraw node still show up? What is user code supposed to match to detect a U2F device or to otherwise set permissions? The only change with what we currently have is that the modalias of the device will be something like MODALIAS=hid:b0003gHID_GROUP_U2Fvp. (replace HID_GROUP_U2F with the proper hex value). So matching against this modalias is trivial, and you can just put the hidraw node rw for users. Do we really want udev matching against MODALIAS, and do we really want udev rules to hardcode hid group constants? That's a good question. I don't think the hid group will change in the future and we can guarantee that in the kernel I think. I'd like this idea better if we added a HID_GROUP uevent property with a textual description, or perhaps something a little more specific. This refers back to Jiri's first remark. Adding such a thing is doable, but do we really want/need it :/ I would tend to think that designing a HID interface for userspace consumption might be a hint that it's the right time to give it a better name than MODALIAS :) --Andy The hid group field seems to be used for different types of things. yes, my proposal is definitively a (ugly) hack around the groups which are used to select which hid subdriver we use. An other question which comes to my mind is don't we want logind to assign the hidraw node to the proper client? We may still need to tag the device somehow, but if logind prevents untrusted application to run arbitrary code on the u2f token, that might be a little bit safer than allowing anybody to read/write. We do want it to be assigned to the proper client. My udev patch (which will almost certainly not be accepted as-is, but it could be fixed up) uses the report_descriptor to set ID_SECURITY_TOKEN=1, which in turn causes an existing rule to set TAG+=uaccess, which causes logind to do its thing. Sorry to raise more questions than providing answers. No problem. --Andy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
