- 16 Mar, 2015 13 commits
-
-
Johan Hedberg authored
If the SMP Pairing Request or Response PDU received from the remote device indicates that it has received our OOB data we should set the SMP_FLAG_LOCAL_OOB flag. Signed-off-by:
Johan Hedberg <johan.hedberg@intel.com> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org>
-
Johan Hedberg authored
There are several decisions in the SMP logic that depend not only on whether we're doing SMP or not, but also whether local and/or remote OOB data is present. This patch splits the existing SMP_FLAG_OOB into two new flags to track local and remote OOB data respectively. Signed-off-by:
-
Johan Hedberg authored
We need to store the local ra/rb value in order to verify the Check value received from the remote. This patch adds a new 'lr' for the local ra/rb value and makes sure it gets used when verifying the DHKey Check PDU received from the remote. Signed-off-by:
-
Marcel Holtmann authored
Signed-off-by:
-
Marcel Holtmann authored
The OOB public and secret key pair is different from the non-OOB pairing procedure. SO when OOB method is in use, then use this key pair instead of generating a new one. Signed-off-by:
-
Marcel Holtmann authored
Then the local out-of-band data for LE SC pairing is requested via Read Local OOB Extended Data command, then fill in the values generated by the smp_generate_oob function. Every call of this command will overwrite previously generated values. Signed-off-by:
-
Marcel Holtmann authored
This patch adds a smp_generate_oob function that allows to create local out-of-band data that can be used for pairing and also provides the confirmation and random value. Signed-off-by:
-
Marcel Holtmann authored
The security manager device will require the use of AES-CMAC hash for out-of-band data generation. This patch makes sure it is correctly set up and available. Signed-off-by:
-
Marcel Holtmann authored
The LE Secure Connections Confirmation Value and LE Secure Connections Random Value contants are required for the out-of-band data and so just define them. Signed-off-by:
-
Marcel Holtmann authored
Every Bluetooth Low Energy controller requires a local crypto context to handle the resolvable private addresses. At the moment this is just a single crypto context, but for out-of-band data generation it will require an additional. To facility this, create a struct smp_dev that will hold all the extra information. This patch is just the refactoring in preparation for future changes. Signed-off-by:
-
Marcel Holtmann authored
Within the security manager, it makes sense to use kzfree instead of kfree for all data structures. This ensures that no key material leaks by accident. Signed-off-by:
-
Marcel Holtmann authored
The HCI_CONN_REMOTE_OOB connection flag is used to indicate if the pairing initiator has provided out-of-band data. However since that value is no longer used in any decision making, just remove it. It is actually unclear what purpose the OOB data present field from the HCI IO Capability Response event serves in the first place. If either side provided out-of-band data, then that data will be used for pairing. Signed-off-by:
-
Marcel Holtmann authored
When only the pairing initiator is providing out-of-band data, then the receiver side was ignoring the data. For some reason the code was checking if the initiator has received out-of-band data and only then also provide the required inidication that the acceptor actually has the needed data available. For BR/EDR out-of-band pairing it is enough if one side has received out-of-band data. There are no extra checks needed here to make this work smoothly. The only thing that is needed is to tell the controller if data is present (and if it is P-192 or P-256 or both) and then let the controller actually figure out the rest. This means the check for outgoing connection or if the initiator has indicated data are completely pointless and are in fact actually causing harm. The check in question is this one: if (conn->out || test_bit(HCI_CONN_REMOTE_OOB, &conn->flags)) { After just taking the conditional check out and always executing the code for determining the type of out-of-band data, the pairing works flawlessly and prodcudes authenticated link keys. The patch itself looks more complicated due to the reformatting of the indentation, but it essentially just a two-line change. Signed-off-by:
-
- 15 Mar, 2015 18 commits
-
-
Marcel Holtmann authored
This adds support for the simplest possible version of Read Local OOB Extended Data management command. It includes all mandatory fields, but none of the actual pairing related ones. Signed-off-by:
-
Marcel Holtmann authored
The OOB data requires to include LE Bluetooth Device Address and LE Role and so add the type constants for these fields. Signed-off-by:
-
Marcel Holtmann authored
The eir_append_data helper function is needed for generating the extended local OOB data fields. So move it up into the right location. Signed-off-by:
-
Marcel Holtmann authored
This adds support for the simplest possible version of Read Advertising Features management command. It allows basic testing of the interface. Signed-off-by:
-
Marcel Holtmann authored
The flags for the management command table used manual encoding of bits in the form of (1 << n). It is however preferred to use BIT(n) macro instead. Signed-off-by:
-
Marcel Holtmann authored
Changes to the global configuration updates like settings, class of device, name etc. can be received by every user. They are allowed to read them in the first place so provide the updates via events as well. Otherwise untrusted users start polling for updates and that is not a desired behavior. Signed-off-by:
-
Marcel Holtmann authored
Until now the management interface was restricted to CAP_NET_ADMIN. With this change every user can open the management socket. However the list of commands is heavily restricted to getting basic information about the attached controllers. No access for configuration or other operation is provided. The events are also limited. This is done so that no keys can leak or untrusted users can mess with the Bluetooth configuration. Signed-off-by:
-
Marcel Holtmann authored
Check the required trust level of each management command with the trust level of the management socket. If it does not match up, then return the newly introduced permission denied error. Signed-off-by:
-
Marcel Holtmann authored
The flags field for the management command table will be always initialized to zero and thus no need to do that manually. Signed-off-by:
-
Marcel Holtmann authored
Some management commands are safe to be accessed from any user without special permissions. First step for allowing access to any of these commands from untrusted application is to mark them accordingly. Signed-off-by:
-
Marcel Holtmann authored
The management interface will need access to the socket flags and so provide a helper function for checking them. Signed-off-by:
-
Marcel Holtmann authored
With the introduction of trusted socket flag for control and monitor channels, it is now possible to use a single function for sending packets to these sockets. And with that consolidate the handling. Signed-off-by:
-
Marcel Holtmann authored
Providing a global trusted flag for management control sockets provides an easy way for identifying sockets and imposing restriction on it. For now all management sockets are trusted since they require CAP_NET_ADMIN. Signed-off-by:
-
Marcel Holtmann authored
The Read Extended Contoller Index List command can be used for retrieving the complete list of local available controllers. This included configured, unconfigured and also AMP controllers. Signed-off-by:
-
Marcel Holtmann authored
This introduces support for using Extended Index Added and Extended Index Removed events. These events contain the controller type and also the hardware bus information from the driver. Signed-off-by:
-
Marcel Holtmann authored
For sending Index Added, Index Removed, Unconfigured Index Added and Unconfigured Index Removed managment events the new helper functions allows taking into account if these events are enabled for a certain management socket or not. Signed-off-by:
-
Marcel Holtmann authored
The hci_send_to_flagged_channel helper function can be used to send packets to all channels that have a certain HCI socket flag set. This is especially useful for managment events that are limited to sockets that have first enabled certain functionality. This allows for filtering of events without confusing existing users. Signed-off-by:
-
Marcel Holtmann authored
To filter out certain actions for certain HCI sockets introcuce a flags field that allows to configure specific settings on individual sockets. Since the hci_pinfo structure is private in hci_sock.c, provide helper functions for setting and clearing a given flag. Signed-off-by:
-
- 14 Mar, 2015 9 commits
-
-
Florian Fainelli authored
Commit cd28a1a9 ("net: dsa: fully divert PHY reads/writes if requested") introduced a check for particular PHYs that need to be accessed using the slave MII bus created by DSA, but this check was too inclusive. This would prevent fixed PHYs from being successfully registered because those should not go through the slave MII bus created by DSA. Make sure we check that the PHY is not a fixed PHY to prevent that from happening. Fixes: cd28a1a9 ("net: dsa: fully divert PHY reads/writes if requested") Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queueDavid S. Miller authored
Jeff Kirsher says: ==================== Intel Wired LAN Driver Updates 2015-03-13 This series contains updates to ixgbe and ixgbevf. Don adds additional support for X550 MAC types, which require additional steps around enabling and disabling Rx. Also cleans up variable type inconsistency. I provide a patch to allow relaxed ordering to be enabled on SPARC architectures. Also cleans up ixgbevf whitespace and code comments to align the driver with networking coding standard. Lastly cleaned up uses of memcpy() where ether_addr_copy() could have been used. Alex removes some dead code in the ixgbe cleanup patch. ==================== Signed-off-by: -
David S. Miller authored
Eric Dumazet says: ==================== inet: tcp listener refactoring, part 9 This preliminary work pushes socket convergence a bit more: 1) request sock ir_iif is universally set 2) inet_diag can use common helpers to reduce LOC ==================== Signed-off-by: -
Eric Dumazet authored
Now the three type of sockets share a common base, we can factorize code in inet_diag_msg_common_fill(). inet_diag_entry no longer requires saddr_storage & daddr_storage and the extra copies. Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
-
Eric Dumazet authored
inet_sk_diag_fill() only copes with non timewait and non request socks Signed-off-by:
-
Eric Dumazet authored
Once request socks will be in ehash table, they will need to have a valid ir_iff field. This is currently true only for IPv6. This patch extends support for IPv4 as well. This means inet_diag_fill_req() can now properly use ir_iif, which is better for IPv6 link locals anyway, as request sockets and established sockets will propagate consistent netlink idiag_if. Signed-off-by:
-
David S. Miller authored
Jon Maloy says: ==================== tipc: some optimizations and impovements The commits in this series contain some relatively simple changes that lead to better throughput across TIPC connections. We also make changes to the implementation of link transmission queueing and priority handling, in order to make the code more comprehensible and maintainable. v2: Commit #2: Redesigned tipc_msg_validate() to use pskb_may_pull(), as per feedback from David Miller. Commit #3: Some cosmetic changes to tipc_msg_extract(). I tried to replace the unconditional skb_linearize() with calls to pskb_may_pull() at selected locations, but I gave up. First, skb_trim() requires a fully linearized buffer. Second, it doesn't make much sense; the whole buffer will end up linearized, one way or another. ==================== Signed-off-by: -
Jon Paul Maloy authored
Messages transferred by TIPC are assigned an "importance priority", -an integer value indicating how to treat the message when there is link or destination socket congestion. There is no separate header field for this value. Instead, the message user values have been chosen in ascending order according to perceived importance, so that the message user field can be used for this. This is not a good solution. First, we have many more users than the needed priority levels, so we end up with treating more priority levels than necessary. Second, the user field cannot always accurately reflect the priority of the message. E.g., a message fragment packet should really have the priority of the enveloped user data message, and not the priority of the MSG_FRAGMENTER user. Until now, we have been working around this problem in different ways, but it is now time to implement a consistent way of handling such priorities, although still within the constraint that we cannot allocate any more bits in the regular data message header for this. In this commit, we define a new priority level, TIPC_SYSTEM_IMPORTANCE, that will be the only one used apart from the four (lower) user data levels. All non-data messages map down to this priority. Furthermore, we take some free bits from the MSG_FRAGMENTER header and allocate them to store the priority of the enveloped message. We then adjust the functions msg_importance()/msg_set_importance() so that they read/set the correct header fields depending on user type. This small protocol change is fully compatible, because the code at the receiving end of a link currently reads the importance level only from user data messages, where there is no change. Reviewed-by:
Erik Hugne <erik.hugne@ericsson.com> Signed-off-by:
Jon Maloy <jon.maloy@ericsson.com> Signed-off-by:
-
Jon Paul Maloy authored
struct tipc_link contains one single queue for outgoing packets, where both transmitted and waiting packets are queued. This infrastructure is hard to maintain, because we need to keep a number of fields to keep track of which packets are sent or unsent, and the number of packets in each category. A lot of code becomes simpler if we split this queue into a transmission queue, where sent/unacknowledged packets are kept, and a backlog queue, where we keep the not yet sent packets. In this commit we do this separation. Reviewed-by:
Ying Xue <ying.xue@windriver.com> Signed-off-by:
-
