Hi Waldek, On Fri, Aug 27, 2010, Waldemar.Rymarkiewicz@xxxxxxxxx wrote: > However, I would appreciate any comments to the changes as I'm not > sure what was originally assumed for the high security level. Your assumptions were more or less correct. Additionally there should be the check for encryption key size (to fulfill SAP requirements), though that'd require at least a 3.0 capable controller if for the standardized HCI command. > What's more, I'am not happy that the link key request and the pin code > request are handled in bluez. It makes that bluez need to pass it to > the kernel as it's needed there. I used ioctl for that. Some comments > on this? I'm not happy with it either. In fact, the arbitrary split of security logic between kernel and userspace has caused us lots of grief, especially with SSP. Because of this, the plan for BlueZ 5.x is to move most security related logic to the kernel side. The only thing remaining in userspace is security policy requiring user interaction (e.g. answering user confirmation requests) and persistent link key storage (runtime storage will be added to the kernel side). The promiscuous HCI socket will go away from bluetoothd so the daemon doesn't always wake up when there's some HCI traffic. To make all this possible we're designing a new protocol between kernel and userspace. Hopefully we'll get the first bits, at least a preliminary specification, upstream within the next month or so. Because of this I'm wondering if the new ioctl that you're adding is really worth it. Maybe we should just wait for BlueZ 5.x with this. That'd also give us the possibility of adding a new parameter to Agent.RequestPinCode since we need to break the agent API anyway (e.g. add an incoming just-works pairing callback). Johan -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
