summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* Bluetooth: Remove hci_h4 unused definesPoulain, Loic2014-04-241-7/+0
| | | | | | | H4 states are not used anymore. Signed-off-by: Loic Poulain <loic.poulain@intel.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
* Bluetooth: btmrvl: Fix btmrvl_send_module_cfg_cmd()Petri Gynther2014-04-242-2/+2
| | | | | | | | | Change subcmd parameter from int to u8 to match its use: btmrvl_send_sync_cmd(priv, BT_CMD_MODULE_CFG_REQ, &subcmd, 1); Signed-off-by: Petri Gynther <pgynther@google.com> Reviewed-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Return EOPNOTSUPP for HCISETRAW ioctl commandMarcel Holtmann2014-04-241-10/+1
| | | | | | | | | | | | | | The HCISETRAW ioctl command is not really useful. To utilize raw and direct access to the HCI controller, the HCI User Channel feature has been introduced. Return EOPNOTSUPP to indicate missing support for this command. For legacy reasons hcidump used to use HCISETRAW for permission check to return proper error codes to users. To keep backwards compability return EPERM in case the caller does not have CAP_NET_ADMIN capability. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Request MITM Protection when initiatorMikel Astiz2014-04-111-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | The GAP Specification gives the flexibility to decide whether MITM Protection is requested or not (Bluetooth Core Specification v4.0 Volume 3, part C, section 6.5.3) when replying to an HCI_EV_IO_CAPA_REQUEST event. The recommendation is *not* to set this flag "unless the security policy of an available local service requires MITM Protection" (regardless of the bonding type). However, the kernel doesn't necessarily have this information and therefore the safest choice is to always use MITM Protection, also for General Bonding. This patch changes the behavior for the General Bonding initiator role, always requesting MITM Protection even if no high security level is used. Depending on the remote capabilities, the protection might not be actually used, and we will accept this locally unless of course a high security level was originally required. Note that this was already done for Dedicated Bonding. No-Bonding is left unmodified because MITM Protection is normally not desired in these cases. Signed-off-by: Mikel Astiz <mikel.astiz@bmw-carit.de> Signed-off-by: Timo Mueller <timo.mueller@bmw-carit.de> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Use MITM Protection when IO caps allow itTimo Mueller2014-04-111-7/+2
| | | | | | | | | | | | | | | | | | | | | | | | | When responding to a remotely-initiated pairing procedure, a MITM protected SSP associaton model can be used for pairing if both local and remote IO capabilities are set to something other than NoInputNoOutput, regardless of the bonding type (Dedicated or General). This was already done for Dedicated Bonding but this patch proposes to use the same policy for General Bonding as well. The GAP Specification gives the flexibility to decide whether MITM Protection is used ot not (Bluetooth Core Specification v4.0 Volume 3, part C, section 6.5.3). Note however that the recommendation is *not* to set this flag "unless the security policy of an available local service requires MITM Protection" (for both Dedicated and General Bonding). However, as we are already requiring MITM for Dedicated Bonding, we will follow this behaviour also for General Bonding. Signed-off-by: Timo Mueller <timo.mueller@bmw-carit.de> Signed-off-by: Mikel Astiz <mikel.astiz@bmw-carit.de> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Refactor code for outgoing dedicated bondingMikel Astiz2014-04-112-10/+9
| | | | | | | | | | | | | Do not always set the MITM protection requirement by default in the field conn->auth_type, since this will be added later in hci_io_capa_request_evt(), as part of the requirements specified in HCI_OP_IO_CAPABILITY_REPLY. This avoids a hackish exception for the auto-reject case, but doesn't change the behavior of the code at all. Signed-off-by: Mikel Astiz <mikel.astiz@bmw-carit.de> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Refactor hci_get_auth_req()Mikel Astiz2014-04-111-15/+22
| | | | | | | | | Refactor the code without changing its behavior by handling the no-bonding cases first followed by General Bonding. Signed-off-by: Mikel Astiz <mikel.astiz@bmw-carit.de> Signed-off-by: Timo Mueller <timo.mueller@bmw-carit.de> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Fix address in unmergeable device found eventsJohan Hedberg2014-03-291-3/+2
| | | | | | | | | | | | | When sending out a device found event caused by an advertising report in the situation where we couldn't store the report as a pending one, the code was incorrectly trying to use the address and address type from the pending data. Since the pending data is cleared in the previous line this causes a potentially incorrect address type and an address of BDADDR_ANY. This patch fixes the call to use the address information correctly from the received advertising report. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: btmrvl: implement read-to-clear for SD8897 interruptsBing Zhao2014-03-284-1/+73
| | | | | | | | | For SD8897, CMD52 write_to_clear may have missing interrupts under certain corner case condition. Use CMD53 read-to-clear to fix the problem. Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Keep msec in DISCOV_LE_TIMEOUTLukasz Rymanowski2014-03-282-2/+2
| | | | | | | | | | To be consistent, lets use msec for this timeout as well. Note: This define value is a minimum scan time taken from BT Core spec 4.0, Vol 3, Part C, chapter 9.2.6 Signed-off-by: Lukasz Rymanowski <lukasz.rymanowski@tieto.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Add new debugfs parameterLukasz Rymanowski2014-03-283-1/+6
| | | | | | | | | | With this patch it is possible to control discovery interleaved timeout value from debugfs. It is for fine tuning of this timeout. Signed-off-by: Lukasz Rymanowski <lukasz.rymanowski@tieto.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Keep msec in DISCOV_INTERLEAVED_TIMEOUTLukasz Rymanowski2014-03-282-5/+10
| | | | | | | | | | | Keep msec instead of jiffies in this define. This is needed by following patch where we want this timeout to be exposed in debugfs. Note: Value of this timeout comes from recommendation in BT Core Spec.4.0, Vol 3, Part C, chapter 13.2.1. Signed-off-by: Lukasz Rymanowski <lukasz.rymanowski@tieto.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: btmrvl: separate write-to-clear function from interrupt handlerBing Zhao2014-03-281-21/+32
| | | | | | | This patch improves readability and makes future changes easier. Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Remove unnecessary NULL check in hci_inquiry_cache_updateJohan Hedberg2014-03-271-1/+1
| | | | | | | | | The ssp parameter is supposed to be a mandatory one and there are no callers that would pass NULL to this function. Removing this unnecessary NULL check also makes (false positive) static analyzer warnings go away. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Fix RSSI value in device found event from disabling scanJohan Hedberg2014-03-261-2/+3
| | | | | | | | When sending a pending device found event triggered by disabling LE scanning we should use the stored RSSI instead of sending a zero value. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Store also RSSI for pending advertising reportsJohan Hedberg2014-03-262-5/+8
| | | | | | | | | | | | | | | | Especially in crowded environments it can become frequent that we have to send out whatever pending event there is stored. Since user space has its own filtering of small RSSI changes sending a 0 value will essentially force user space to wake up the higher layers (e.g. over D-Bus) even though the RSSI didn't actually change more than the threshold value. This patch adds storing also of the RSSI for pending advertising reports so that we report an as accurate RSSI as possible when we have to send out the stored information to user space. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Don't send device found events for duplicate reportsJohan Hedberg2014-03-261-7/+12
| | | | | | | | | | Occasionally, during active scanning we will receive duplicate ADV_IND reports from the same device before receiving the SCAN_RSP from them. In order to not wake up user space unnecessarily it's better not to send these extra events as they do not contain any new information. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Fix line splitting of mgmt_device_found parametersJohan Hedberg2014-03-262-4/+4
| | | | | | | | The line was incorrectly split between the variable type and its name. This patch fixes the issue. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Remove redundant NULL checkJohan Hedberg2014-03-261-2/+1
| | | | | | | | | All callers of hci_inquiry_cache_update() pass a non-NULL ssp pointer to it and even the function itself assumes in another place that the pointer is non-NULL. Therefore, remove the redundant check. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Merge ADV_IND/ADV_SCAN_IND and SCAN_RSP togetherJohan Hedberg2014-03-262-2/+105
| | | | | | | | | | | | | | | | | | | | | | | | | | To avoid too many events being sent to user space and to help parsing of all available remote device data it makes sense for us to wait for the scan response and send a single merged Device Found event to user space. This patch adds a few new variables to hci_dev to track the last received ADV_IND/ADV_SCAN_IND, i.e. those which will cause a SCAN_REQ to be send in the case of active scanning. When the SCAN_RSP is received the pending data is passed together with the SCAN_RSP to the mgmt_device_found function which takes care of merging them into a single Device Found event. We also need a bit of extra logic to handle situations where we don't receive a SCAN_RSP after caching some data. In such a scenario we simply have to send out the pending data as it is and then operate on the new report as if there was no pending data. We also need to send out any pending data when scanning stops as well as ensure that the storage is empty at the start of a new active scanning session. These both cases are covered by the update to the hci_cc_le_set_scan_enable function in this patch. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Add directed advertising support through connect()Johan Hedberg2014-03-263-10/+87
| | | | | | | | | | | | | When we're in peripheral mode (HCI_ADVERTISING flag is set) the most natural mapping of connect() is to perform directed advertising to the peer device. This patch does the necessary changes to enable directed advertising and keeps the hci_conn state as BT_CONNECT in a similar way as is done for central or BR/EDR connection initiation. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Add scan_rsp parameter to mgmt_device_found()Johan Hedberg2014-03-263-12/+19
| | | | | | | | | | | In preparation for being able to merge ADV_IND/ADV_SCAN_IND and SCAN_RSP together into a single device found event add a second parameter to the mgmt_device_found function. For now all callers pass NULL as this parameters since we don't yet have storing of the last received advertising report. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Don't send device found events during passive scanningJohan Hedberg2014-03-261-2/+6
| | | | | | | | | Passive LE scanning is only used by the kernel-internal connection establishment procedure. It makes therefore little sense to send device found events to user space. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Add error mapping for Directed Advertising TimeoutJohan Hedberg2014-03-261-0/+1
| | | | | | | | | When a timeout occurs using directed advertising a 0x3c error gets generated. Since the operation is analogous to conventional connection creation map this to the usual EHOSTDOWN error. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Fix LE responder/initiator address settingJohan Hedberg2014-03-261-12/+14
| | | | | | | | | | | | | | Once directed advertising is brought into the picture simply the lack of an hci_conn object when an le_conn_complete event occurs is no longer a reliable indication that the responder & initiator values need to be set based on our advertising address type. This patch moves the code for setting these values outside of the "if (!conn)" branch and ensures that they get set for any connection where we are in the slave role. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Move local identity address setting to a central placeJohan Hedberg2014-03-262-16/+4
| | | | | | | | | | | Any time hci_conn_add is used for an LE connection we need to ensure that the local identity address is correctly described in the src and src_type variables. This patch moves setting these values directly into hci_conn_add so that callers don't have to duplicate the effort themselves. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Use memdup_user in le_auto_conn_write()Andre Guedes2014-03-261-8/+3
| | | | | | | | | This patch does a small code simplification replacing the tipical kmalloc-copy_from_user sequence by memdup_user() helper. Cc: Fengguang Wu <fengguang.wu@intel.com> Signed-off-by: Andre Guedes <andre.guedes@openbossa.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Refactor advertising report processing into its own functionJohan Hedberg2014-03-261-8/+13
| | | | | | | | | | As preparation for merging ADV_IND/ADV_SCAN_IND and SCAN_RSP together into a single mgmt Device Found event refactor individual advertising report handling into a separate function. This will help keep the code more readable as more logic gets added. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Fix returning peer address in pending connect stateJohan Hedberg2014-03-262-2/+4
| | | | | | | | | | | | | | | | We should let user space request the peer address also in the pending connect states, i.e. BT_CONNECT and BT_CONNECT2. There is existing user space code that tries to do this and will fail without extending the set of allowed states for the peer address information. This patch adds the two states to the allowed ones in the L2CAP and RFCOMM sock_getname functions, thereby preventing ENOTCONN from being returned. Reported-by: Andrzej Kaczmarek <andrzej.kaczmarek@tieto.com> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Tested-by: Andrzej Kaczmarek <andrzej.kaczmarek@tieto.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Remove unnecessary assignment in SMPJohan Hedberg2014-03-241-2/+0
| | | | | | | | | The smp variable in smp_conn_security is not used anywhere before the smp = smp_chan_create() call in the smp_conn_security function so it makes no sense to assign any other value to it before that. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Fix potential NULL pointer dereference in smp_conn_securityJohan Hedberg2014-03-241-1/+1
| | | | | | | | | | | | The smp pointer might not be initialized for jumps to the "done" label in the smp_conn_security function. Furthermore doing the set_bit after done might "overwrite" a previous value of the flag in case pairing was already in progress. This patch moves the call to set_bit before the label so that it is only done for a newly created smp context (as returned by smp_chan_create). Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Remove LTK re-encryption procedureJohan Hedberg2014-03-242-49/+7
| | | | | | | | | Due to several devices being unable to handle this procedure reliably (resulting in forced disconnections before pairing completes) it's better to remove it altogether. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Don't try to confirm locally initiated SMP pairingJohan Hedberg2014-03-241-0/+5
| | | | | | | | | | | In the case that the just-works model would be triggered we only want to confirm remotely initiated pairings (i.e. those triggered by a Security Request or Pairing Request). This patch adds the necessary check to the tk_request function to fall back to the JUST_WORKS method in the case of a locally initiated pairing. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Add SMP flag to track which side is the initiatorJohan Hedberg2014-03-242-0/+7
| | | | | | | | | | | For remotely initiated just-works pairings we want to show the user a confirmation dialog for the pairing. However, we can only know which side was the initiator by tracking which side sends the first Security Request or Pairing Request PDU. This patch adds a new SMP flag to indicate whether our side was the initiator for the pairing. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Fix SMP confirmation callback handlingJohan Hedberg2014-03-241-0/+4
| | | | | | | | | | | | In the case that a local pairing confirmation (JUST_CFM) has been selected as the method we need to use the user confirm request mgmt event for it with the confirm_hint set to 1 (to indicate confirmation without any specific passkey value). Without this (if passkey_notify was used) the pairing would never proceed. This patch adds the necessary call to mgmt_user_confirm_request in this scenario. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Add missing cmd_status handler for LE_Start_EncryptionJohan Hedberg2014-03-241-0/+34
| | | | | | | | | | | It is possible that the HCI_LE_Start_Encryption command fails in an early stage and triggers a command status event with the failure code. In such a case we need to properly notify the hci_conn object and cleanly bring the connection down. This patch adds the missing command status handler for this HCI command. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Fix potential NULL pointer dereference in SMPJohan Hedberg2014-03-241-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If a sudden disconnection happens the l2cap_conn pointer may already have been cleaned up by the time hci_conn_security gets called, resulting in the following oops if we don't have a proper NULL check: BUG: unable to handle kernel NULL pointer dereference at 000000c8 IP: [<c132e2ed>] smp_conn_security+0x26/0x151 *pde = 00000000 Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC CPU: 1 PID: 673 Comm: memcheck-x86-li Not tainted 3.14.0-rc2+ #437 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 task: f0ef0520 ti: f0d6a000 task.ti: f0d6a000 EIP: 0060:[<c132e2ed>] EFLAGS: 00010246 CPU: 1 EIP is at smp_conn_security+0x26/0x151 EAX: f0ec1770 EBX: f0ec1770 ECX: 00000002 EDX: 00000002 ESI: 00000002 EDI: 00000000 EBP: f0d6bdc0 ESP: f0d6bda0 DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 CR0: 80050033 CR2: 000000c8 CR3: 30f0f000 CR4: 00000690 Stack: f4f55000 00000002 f0d6bdcc c1097a2b c1319f40 f0ec1770 00000002 f0d6bdd0 f0d6bde8 c1312a82 f0d6bdfc c1312a82 c1319f84 00000008 f4d81c20 f0e5fd86 f0ec1770 f0d6bdfc f0d6be28 c131be3b c131bdc1 f0d25270 c131be3b 00000008 Call Trace: [<c1097a2b>] ? __kmalloc+0x118/0x128 [<c1319f40>] ? mgmt_pending_add+0x49/0x9b [<c1312a82>] hci_conn_security+0x4a/0x1dd [<c1312a82>] ? hci_conn_security+0x4a/0x1dd [<c1319f84>] ? mgmt_pending_add+0x8d/0x9b [<c131be3b>] pair_device+0x1e1/0x206 [<c131bdc1>] ? pair_device+0x167/0x206 [<c131be3b>] ? pair_device+0x1e1/0x206 [<c131ed44>] mgmt_control+0x275/0x2d6 Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: bluecard: Use del_timer_sync() in teardown pathThomas Gleixner2014-03-231-1/+1
| | | | | | | | Make sure no timer callback is running before releasing the datastructure which contains it. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Track current configured LE scan type parameterMarcel Holtmann2014-03-212-0/+26
| | | | | | | | | The LE scan type paramter defines if active scanning or passive scanning is in use. Track the currently set value so it can be used for decision making from other pieces in the core. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: btmrvl: don't consume all vendor specific eventsAmitkumar Karwar2014-03-201-5/+6
| | | | | | | | | | | | | | | | If vendor specific HCI commands are received from application, we should send corresponding events to stack. These events should be consumed in driver, only if they are for the internal HCI commands generated by driver. This patch fixes the vendor command 0x3f stuck problem with above mentioned change. For example, hcitool cmd 3f 22 fe 06 22 21 20 43 50 00 Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Fix address value for early disconnection eventsJohan Hedberg2014-03-202-21/+11
| | | | | | | | | | | | | | | | | | We need to ensure that we do not send events to user space with the identity address if we have not yet notified user space of the IRK. The code was previously trying to handle this for the mgmt_pair_device response (which worked well enough) but this is not the only connection related event that might be sent to user space before pairing is successful: another important event is Device Disconnected. The issue can actually be solved more simply than the solution previously used for mgmt_pair_device. Since we do have the identity address tracked as part of the remote IRK struct we can just copy it over from there to the hci_conn struct once we've for real sent the mgmt event for the new IRK. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Fix passkey endianess in user_confirm and notify_passkeyJohan Hedberg2014-03-194-6/+6
| | | | | | | | | | | The passkey_notify and user_confirm functions in mgmt.c were expecting different endianess for the passkey, leading to a big endian bug and sparse warning in recently added SMP code. This patch converts both functions to expect host endianess and do the conversion to little endian only when assigning to the mgmt event struct. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Enforce strict Secure Connections Only mode securityMarcel Holtmann2014-03-192-0/+23
| | | | | | | | | | In Secure Connections Only mode, it is required that Secure Connections is used for pairing and that the link key is encrypted with AES-CCM using a P-256 authenticated combination key. If this is not the case, then new connection shall be refused or existing connections shall be dropped. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Fix Pair Device response parameters for pairing failureJohan Hedberg2014-03-191-2/+14
| | | | | | | | | | | | | | | It is possible that pairing fails after we've already received remote identity information. One example of such a situation is when re-encryption using the LTK fails. In this case the hci_conn object has already been updated with the identity address but user space does not yet know about it (since we didn't notify it of the new IRK yet). To ensure user space doesn't get a Pair Device command response with an unknown address always use the same address in the response as was used for the original command. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Fix SMP user passkey notification mgmt eventJohan Hedberg2014-03-191-2/+3
| | | | | | | | | | | | | | | When performing SMP pairing with MITM protection one side needs to enter the passkey while the other side displays to the user what needs to be entered. Nowhere in the SMP specification does it say that the displaying side needs to any kind of confirmation of the passkey, even though a code comment in smp.c implies this. This patch removes the misleading comment and converts the code to use the passkey notification mgmt event instead of the passkey confirmation mgmt event. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Increase SMP re-encryption delay to 500msJohan Hedberg2014-03-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In some cases the current 250ms delay is not enough for the remote to receive the keys, as can be witnessed by the following log: > ACL Data RX: Handle 64 flags 0x02 dlen 21 [hci1] 231.414217 SMP: Signing Information (0x0a) len 16 Signature key: 555bb66b7ab3abc9d5c287c97fe6eb29 < ACL Data TX: Handle 64 flags 0x00 dlen 21 [hci1] 231.414414 SMP: Encryption Information (0x06) len 16 Long term key: 2a7cdc233c9a4b1f3ed31dd9843fea29 < ACL Data TX: Handle 64 flags 0x00 dlen 15 [hci1] 231.414466 SMP: Master Identification (0x07) len 10 EDIV: 0xeccc Rand: 0x322e0ef50bd9308a < ACL Data TX: Handle 64 flags 0x00 dlen 21 [hci1] 231.414505 SMP: Signing Information (0x0a) len 16 Signature key: bbda1b2076e2325aa66fbcdd5388f745 > HCI Event: Number of Completed Packets (0x13) plen 5 [hci1] 231.483130 Num handles: 1 Handle: 64 Count: 2 < HCI Command: LE Start Encryption (0x08|0x0019) plen 28 [hci1] 231.664211 Handle: 64 Random number: 0x5052ad2b75fed54b Encrypted diversifier: 0xb7c2 Long term key: a336ede66711b49a84bde9b41426692e > HCI Event: Command Status (0x0f) plen 4 [hci1] 231.666937 LE Start Encryption (0x08|0x0019) ncmd 1 Status: Success (0x00) > HCI Event: Number of Completed Packets (0x13) plen 5 [hci1] 231.712646 Num handles: 1 Handle: 64 Count: 1 > HCI Event: Disconnect Complete (0x05) plen 4 [hci1] 232.562587 Status: Success (0x00) Handle: 64 Reason: Remote User Terminated Connection (0x13) As can be seen, the last key (Signing Information) is sent at 231.414505 but the completed packets event for it comes only at 231.712646, i.e. roughly 298ms later. To have a better margin of error this patch increases the delay to 500ms. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Simplify logic when checking SMP_FLAG_TK_VALIDJohan Hedberg2014-03-191-4/+2
| | | | | | | | | This is a trivial coding style simplification by instead of having an extra early return to instead revert the if condition and do the single needed queue_work() call there. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Fix MITM flag when initiating SMP pairingJohan Hedberg2014-03-181-0/+6
| | | | | | | | | | | The pairing process initiated through mgmt sets the conn->auth_type value regardless of BR/EDR or LE pairing. This value will contain the MITM flag if the local IO capability allows it. When sending the SMP pairing request we should check the value and ensure that the MITM bit gets correctly set in the bonding flags. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Fix smp_e byte order to be consistent with SMP specificationJohan Hedberg2014-03-181-55/+46
| | | | | | | | | | | | | | | | | The SMP specification is written with the assumption that both key information, plaintextData and encryptedData follow the same little endian byte ordering as the rest of SMP. Since the kernel crypto routines expect big endian data the code has had to do various byte swapping tricks to make the behavior as expected, however the swapping has been scattered all around the place. This patch centralizes the byte order swapping into the smp_e function by making its public interface match what the other SMP functions expect as per specification. The benefit is vastly simplified calls to smp_e. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Fix const declaration for swap function src parameterJohan Hedberg2014-03-181-2/+2
| | | | | | | | | To make it possible to (correctly) pass data declared as const as the src parameter to the swap56 and swap128 functions declare this parameter also as const. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
OpenPOWER on IntegriCloud