Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 24 8月, 2009 1 次提交
  3. 23 8月, 2009 13 次提交
  5. 08 6月, 2009 6 次提交
  7. 27 2月, 2009 19 次提交
    • W
      Bluetooth: Remove some pointless conditionals before kfree_skb() · 7585b97a
      由 Wei Yongjun 提交于 
      Remove some pointless conditionals before kfree_skb().
Signed-off-by: NWei Yongjun <yjwei@cn.fujitsu.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      7585b97a
    • M
      Bluetooth: Permit BT_SECURITY also for L2CAP raw sockets · 2526d3d8
      由 Marcel Holtmann 提交于 
      Userspace pairing code can be simplified if it doesn't have to fall
back to using L2CAP_LM in the case of L2CAP raw sockets. This patch
allows the BT_SECURITY socket option to be used for these sockets.
Signed-off-by: NJohan Hedberg <johan.hedberg@nokia.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      2526d3d8
    • M
      Bluetooth: Disallow usage of L2CAP CID setting for now · 2a517ca6
      由 Marcel Holtmann 提交于 
      In the future the L2CAP layer will have full support for fixed channels
and right now it already can export the channel assignment, but for the
functions bind() and connect() the usage of only CID 0 is allowed. This
allows an easy detection if the kernel supports fixed channels or not,
because otherwise it would impossible for application to tell.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      2a517ca6
    • M
      Bluetooth: Fix authentication requirements for L2CAP security check · 00ae4af9
      由 Marcel Holtmann 提交于 
      The L2CAP layer can trigger the authentication via an ACL connection or
later on to increase the security level. When increasing the security
level it didn't use the same authentication requirements when triggering
a new ACL connection. Make sure that exactly the same authentication
requirements are used. The only exception here are the L2CAP raw sockets
which are only used for dedicated bonding.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      00ae4af9
    • M
      Bluetooth: Ask upper layers for HCI disconnect reason · 2950f21a
      由 Marcel Holtmann 提交于 
      Some of the qualification tests demand that in case of failures in L2CAP
the HCI disconnect should indicate a reason why L2CAP fails. This is a
bluntly layer violation since multiple L2CAP connections could be using
the same ACL and thus forcing a disconnect reason is not a good idea.

To comply with the Bluetooth test specification, the disconnect reason
is now stored in the L2CAP connection structure and every time a new
L2CAP channel is added it will set back to its default. So only in the
case where the L2CAP channel with the disconnect reason is really the
last one, it will propagated to the HCI layer.

The HCI layer has been extended with a disconnect indication that allows
it to ask upper layers for a disconnect reason. The upper layer must not
support this callback and in that case it will nicely default to the
existing behavior. If an upper layer like L2CAP can provide a disconnect
reason that one will be used to disconnect the ACL or SCO link.

No modification to the ACL disconnect timeout have been made. So in case
of Linux to Linux connection the initiator will disconnect the ACL link
before the acceptor side can signal the specific disconnect reason. That
is perfectly fine since Linux doesn't make use of this value anyway. The
L2CAP layer has a perfect valid error code for rejecting connection due
to a security violation. It is unclear why the Bluetooth specification
insists on having specific HCI disconnect reason.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      2950f21a
    • M
      Bluetooth: Add CID field to L2CAP socket address structure · f29972de
      由 Marcel Holtmann 提交于 
      In preparation for L2CAP fixed channel support, the CID value of a
L2CAP connection needs to be accessible via the socket interface. The
CID is the connection identifier and exists as source and destination
value. So extend the L2CAP socket address structure with this field and
change getsockname() and getpeername() to fill it in.

The bind() and connect() functions have been modified to handle L2CAP
socket address structures of variable sizes. This makes them future
proof if additional fields need to be added.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      f29972de
    • M
      Bluetooth: Request L2CAP fixed channel list if available · e1027a7c
      由 Marcel Holtmann 提交于 
      If the extended features mask indicates support for fixed channels,
request the list of available fixed channels. This also enables the
fixed channel features bit so remote implementations can request
information about it. Currently only the signal channel will be
listed.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      e1027a7c
    • M
      Bluetooth: Don't enforce authentication for L2CAP PSM 1 and 3 · 435fef20
      由 Marcel Holtmann 提交于 
      The recommendation for the L2CAP PSM 1 (SDP) is to not use any kind
of authentication or encryption. So don't trigger authentication
for incoming and outgoing SDP connections.

For L2CAP PSM 3 (RFCOMM) there is no clear requirement, but with
Bluetooth 2.1 the initiator is required to enable authentication
and encryption first and this gets enforced. So there is no need
to trigger an additional authentication step. The RFCOMM service
security will make sure that a secure enough link key is present.

When the encryption gets enabled after the SDP connection setup,
then switch the security level from SDP to low security.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      435fef20
    • M
      Bluetooth: Fix double L2CAP connection request · 6a8d3010
      由 Marcel Holtmann 提交于 
      If the remote L2CAP server uses authentication pending stage and
encryption is enabled it can happen that a L2CAP connection request is
sent twice due to a race condition in the connection state machine.

When the remote side indicates any kind of connection pending, then
track this state and skip sending of L2CAP commands for this period.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      6a8d3010
    • M
      Bluetooth: Fix race condition with L2CAP information request · 984947dc
      由 Marcel Holtmann 提交于 
      When two L2CAP connections are requested quickly after the ACL link has
been established there exists a window for a race condition where a
connection request is sent before the information response has been
received. Any connection request should only be sent after an exchange
of the extended features mask has been finished.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      984947dc
    • M
      Bluetooth: Use general bonding whenever possible · 0684e5f9
      由 Marcel Holtmann 提交于 
      When receiving incoming connection to specific services, always use
general bonding. This ensures that the link key gets stored and can be
used for further authentications.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      0684e5f9
    • M
      Bluetooth: Don't check encryption for L2CAP raw sockets · 255c7601
      由 Marcel Holtmann 提交于 
      For L2CAP sockets with medium and high security requirement a missing
encryption will enforce the closing of the link. For the L2CAP raw
sockets this is not needed, so skip that check.

This fixes a crash when pairing Bluetooth 2.0 (and earlier) devices
since the L2CAP state machine got confused and then locked up the whole
system.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      255c7601
    • M
      Bluetooth: Update version numbers · 5f9018af
      由 Marcel Holtmann 提交于 
      With the support for the enhanced security model and the support for
deferring connection setup, it is a good idea to increase various
version numbers.

This is purely cosmetic and has no effect on the behavior, but can
be really helpful when debugging problems in different kernel versions.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      5f9018af
    • M
      Bluetooth: Restrict application of socket options · 0588d94f
      由 Marcel Holtmann 提交于 
      The new socket options should only be evaluated for SOL_BLUETOOTH level
and not for every other level. Previously this causes some minor issues
when detecting if a kernel with certain features is available.

Also restrict BT_SECURITY to SOCK_SEQPACKET for L2CAP and SOCK_STREAM for
the RFCOMM protocol.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      0588d94f
    • M
      Bluetooth: Disconnect L2CAP connections without encryption · f62e4323
      由 Marcel Holtmann 提交于 
      For L2CAP connections with high security setting, the link will be
immediately dropped when the encryption gets disabled. For L2CAP
connections with medium security there will be grace period where
the remote device has the chance to re-enable encryption. If it
doesn't happen then the link will also be disconnected.

The requirement for the grace period with medium security comes from
Bluetooth 2.0 and earlier devices that require role switching.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      f62e4323
    • M
      Bluetooth: Replace L2CAP link mode with security level · 2af6b9d5
      由 Marcel Holtmann 提交于 
      Change the L2CAP internals to use the new security levels and remove
the link mode details.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      2af6b9d5
    • M
      Bluetooth: Add enhanced security model for Simple Pairing · 8c1b2355
      由 Marcel Holtmann 提交于 
      The current security model is based around the flags AUTH, ENCRYPT and
SECURE. Starting with support for the Bluetooth 2.1 specification this is
no longer sufficient. The different security levels are now defined as
SDP, LOW, MEDIUM and SECURE.

Previously it was possible to set each security independently, but this
actually doesn't make a lot of sense. For Bluetooth the encryption depends
on a previous successful authentication. Also you can only update your
existing link key if you successfully created at least one before. And of
course the update of link keys without having proper encryption in place
is a security issue.

The new security levels from the Bluetooth 2.1 specification are now
used internally. All old settings are mapped to the new values and this
way it ensures that old applications still work. The only limitation
is that it is no longer possible to set authentication without also
enabling encryption. No application should have done this anyway since
this is actually a security issue. Without encryption the integrity of
the authentication can't be guaranteed.

As default for a new L2CAP or RFCOMM connection, the LOW security level
is used. The only exception here are the service discovery sessions on
PSM 1 where SDP level is used. To have similar security strength as with
a Bluetooth 2.0 and before combination key, the MEDIUM level should be
used. This is according to the Bluetooth specification. The MEDIUM level
will not require any kind of man-in-the-middle (MITM) protection. Only
the HIGH security level will require this.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      8c1b2355
    • M
      Bluetooth: Add support for deferring L2CAP connection setup · f66dc81f
      由 Marcel Holtmann 提交于 
      In order to decide if listening L2CAP sockets should be accept()ed
the BD_ADDR of the remote device needs to be known. This patch adds
a socket option which defines a timeout for deferring the actual
connection setup.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      f66dc81f
    • M
      Bluetooth: Preparation for usage of SOL_BLUETOOTH · d58daf42
      由 Marcel Holtmann 提交于 
      The socket option levels SOL_L2CAP, SOL_RFOMM and SOL_SCO are currently
in use by various Bluetooth applications. Going forward the common
option level SOL_BLUETOOTH should be used. This patch prepares the clean
split of the old and new option levels while keeping everything backward
compatibility.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      d58daf42
  9. 30 11月, 2008 1 次提交