Bluetooth: Preparation for usage of SOL_BLUETOOTH

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: Marcel Holtmann <marcel@holtmann.org>
Bluetooth: Add global deferred socket parameter

The L2CAP and RFCOMM applications require support for authorization
and the ability of rejecting incoming connection requests. The socket
interface is not really able to support this.

This patch does the ground work for a socket option to defer connection
setup. Setting this option allows calling of accept() and then the
first read() will trigger the final connection setup. Calling close()
would reject the connection.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Bluetooth: Add support for deferring RFCOMM connection setup

In order to decide if listening RFCOMM 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.

The connection setup is done after reading from the socket for the
first time. Until then writing to the socket returns ENOTCONN.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Bluetooth: Add support for deferring L2CAP connection setup

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: Marcel Holtmann <marcel@holtmann.org>
Bluetooth: Reject incoming SCO connections without listeners

All SCO and eSCO connection are auto-accepted no matter if there is a
corresponding listening socket for them. This patch changes this and
connection requests for SCO and eSCO without any socket are rejected.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Bluetooth: Fix SCO state handling for incoming connections

When the remote device supports only SCO connections, on receipt of
the HCI_EV_CONN_COMPLETE event packet, the connect state is changed to
BT_CONNECTED, but the socket state is not updated. Hence, the connect()
call times out even though the SCO connection has been successfully
established.

Based on a report by Jaikumar Ganesh <jaikumar@google.com>

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Bluetooth: Add enhanced security model for Simple Pairing

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: Marcel Holtmann <marcel@holtmann.org>
Bluetooth: Replace L2CAP link mode with security level

Change the L2CAP internals to use the new security levels and remove
the link mode details.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Bluetooth: Replace RFCOMM link mode with security level

Change the RFCOMM internals to use the new security levels and remove
the link mode details.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Bluetooth: Pause RFCOMM TX when encryption drops

A role switch with devices following the Bluetooth pre-2.1 standards
or without Encryption Pause and Resume support is not possible if
encryption is enabled. Most newer headsets require the role switch,
but also require that the connection is encrypted.

For connections with a high security mode setting, the link will be
immediately dropped. When the connection uses medium security mode
setting, then a grace period is introduced where the TX is halted and
the remote device gets a change to re-enable encryption after the
role switch. If not re-enabled the link will be dropped.

Based on initial work by Ville Tervo <ville.tervo@nokia.com>

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Bluetooth: Disconnect L2CAP connections without encryption

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: Marcel Holtmann <marcel@holtmann.org>
Bluetooth: Restrict application of socket options

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: Marcel Holtmann <marcel@holtmann.org>
Bluetooth: Update version numbers

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: Marcel Holtmann <marcel@holtmann.org>
Bluetooth: Eliminate a sparse warning in bt3c driver

This eliminates a sparse warning that symbol 'stat' shadows an earlier one.

Signed-off-by: Andre Haupt <andre@bitwigglers.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Bluetooth: When encryption is dropped, do not send RFCOMM packets

During a role change with pre-Bluetooth 2.1 devices, the remote side drops
the encryption of the RFCOMM connection. We allow a grace period for the
encryption to be re-established, before dropping the connection. During
this grace period, the RFCOMM_SEC_PENDING flag is set. Check this flag
before sending RFCOMM packets.

Signed-off-by: Jaikumar Ganesh <jaikumar@google.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Bluetooth: Submit bulk URBs along with interrupt URBs

Submitting the bulk URBs for ACL data transfers only on demand has no
real benefit compared to just submit them when a Bluetooth device gets
opened. So when submitting the interrupt URBs for HCI events, just
submit the bulk URBs, too.

This solves a problem with some Bluetooth USB dongles that has been
reported over the last few month. These devices require that the bulk
URBs are actually present. These devices are really broken, but there
is nothing we can do about it.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Bluetooth: Don't check encryption for L2CAP raw sockets

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: Marcel Holtmann <marcel@holtmann.org>
Bluetooth: Add SCO fallback for eSCO connection attempts

When attempting to setup eSCO connections it can happen that some link
manager implementations fail to properly negotiate the eSCO parameters
and thus fail the eSCO setup. Normally the link manager is responsible
for the negotiation of the parameters and actually fallback to SCO if
no agreement can be reached. In cases where the link manager is just too
stupid, then at least try to establish a SCO link if eSCO fails.

For the Bluetooth devices with EDR support this includes handling packet
types of EDR basebands. This is particular tricky since for the EDR the
logic of enabling/disabling one specific packet type is turned around.
This fix contains an extra bitmask to disable eSCO EDR packet when
trying to fallback to a SCO connection.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Bluetooth: Use general bonding whenever possible

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: Marcel Holtmann <marcel@holtmann.org>
Bluetooth: Set authentication requirements if not available

When no authentication requirements are selected, but an outgoing or
incoming connection has requested any kind of security enforcement,
then set these authentication requirements.

This ensures that the userspace always gets informed about the
authentication requirements (if available). Only when no security
enforcement has happened, the kernel will signal invalid requirements.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>