linux-bluetooth.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Gustavo F. Padovan" <padovan@profusion.mobi>
To: Vinicius Gomes <vinicius.gomes@openbossa.org>
Cc: linux-bluetooth@vger.kernel.org,
	Anderson Briglia <anderson.briglia@openbossa.org>
Subject: Re: [bluetooth-next 04/15] Bluetooth: Add support for using the crypto subsystem
Date: Mon, 28 Feb 2011 14:28:01 -0300	[thread overview]
Message-ID: <20110228172801.GB2165@joana> (raw)
In-Reply-To: <AANLkTi=j3REcNM4bXfFJPamPwqazS5k4eGAJf3BpB_Ya@mail.gmail.com>

Hi Vinicius,

* Vinicius Gomes <vinicius.gomes@openbossa.org> [2011-02-27 21:49:39 -0300]:

> Hi Gustavo,
> 
> On Sun, Feb 27, 2011 at 5:20 PM, Gustavo F. Padovan
> <padovan@profusion.mobi> wrote:
> > Hi Vinicius,
> >
> > * Vinicius Costa Gomes <vinicius.gomes@openbossa.org> [2011-02-21 14:23:51 -0300]:
> >
> >> This will allow using the crypto subsystem for encrypting data. As SMP
> >> (Security Manager Protocol) is implemented almost entirely on the host
> >> side and the crypto module already implements the needed methods
> >> (AES-128), it makes sense to use it.
> >>
> >> This patch also adds a new Kconfig option to toggle the SMP support.
> >>
> >> Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
> >> Signed-off-by: Anderson Briglia <anderson.briglia@openbossa.org>
> >> ---
> >>  include/net/bluetooth/hci_core.h |    2 ++
> >>  net/bluetooth/Kconfig            |    6 ++++++
> >>  net/bluetooth/hci_core.c         |   22 ++++++++++++++++++++++
> >>  net/bluetooth/smp.c              |   17 +++++++++++++++--
> >>  4 files changed, 45 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
> >> index d5d8454..e8dbde8 100644
> >> --- a/include/net/bluetooth/hci_core.h
> >> +++ b/include/net/bluetooth/hci_core.h
> >> @@ -161,6 +161,8 @@ struct hci_dev {
> >>
> >>       __u16                   init_last_cmd;
> >>
> >> +     struct crypto_blkcipher *tfm;
> >> +
> >>       struct inquiry_cache    inq_cache;
> >>       struct hci_conn_hash    conn_hash;
> >>       struct list_head        blacklist;
> >> diff --git a/net/bluetooth/Kconfig b/net/bluetooth/Kconfig
> >> index c6f9c2f..e9f40af 100644
> >> --- a/net/bluetooth/Kconfig
> >> +++ b/net/bluetooth/Kconfig
> >> @@ -22,6 +22,7 @@ menuconfig BT
> >>            BNEP Module (Bluetooth Network Encapsulation Protocol)
> >>            CMTP Module (CAPI Message Transport Protocol)
> >>            HIDP Module (Human Interface Device Protocol)
> >> +          SMP Module (Security Manager Protocol)
> >>
> >>         Say Y here to compile Bluetooth support into the kernel or say M to
> >>         compile it as module (bluetooth).
> >> @@ -35,11 +36,16 @@ config BT_L2CAP
> >>       bool "L2CAP protocol support"
> >>       depends on BT
> >>       select CRC16
> >> +     select CRYPTO_BLKCIPHER
> >> +     select CRYPTO_AES
> >>       help
> >>         L2CAP (Logical Link Control and Adaptation Protocol) provides
> >>         connection oriented and connection-less data transport.  L2CAP
> >>         support is required for most Bluetooth applications.
> >>
> >> +       Also included is support for SMP (Security Manager Protocol) which
> >> +       is the security layer on top of LE (Low Energy) links.
> >> +
> >>  config BT_SCO
> >>       bool "SCO links support"
> >>       depends on BT
> >> diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
> >> index b372fb8..ff67843 100644
> >> --- a/net/bluetooth/hci_core.c
> >> +++ b/net/bluetooth/hci_core.c
> >> @@ -42,6 +42,7 @@
> >>  #include <linux/notifier.h>
> >>  #include <linux/rfkill.h>
> >>  #include <linux/timer.h>
> >> +#include <linux/crypto.h>
> >>  #include <net/sock.h>
> >>
> >>  #include <asm/system.h>
> >> @@ -60,6 +61,8 @@ static void hci_notify(struct hci_dev *hdev, int event);
> >>
> >>  static DEFINE_RWLOCK(hci_task_lock);
> >>
> >> +static int enable_smp;
> >> +
> >>  /* HCI device list */
> >>  LIST_HEAD(hci_dev_list);
> >>  DEFINE_RWLOCK(hci_dev_list_lock);
> >> @@ -1077,6 +1080,14 @@ static void hci_cmd_timer(unsigned long arg)
> >>       tasklet_schedule(&hdev->cmd_task);
> >>  }
> >>
> >> +static struct crypto_blkcipher *alloc_cypher(void)
> >> +{
> >> +     if (enable_smp)
> >> +             return crypto_alloc_blkcipher("ecb(aes)", 0, CRYPTO_ALG_ASYNC);
> >> +
> >> +     return ERR_PTR(-ENOTSUPP);
> >> +}
> >> +
> >>  /* Register HCI device */
> >>  int hci_register_dev(struct hci_dev *hdev)
> >>  {
> >> @@ -1155,6 +1166,11 @@ int hci_register_dev(struct hci_dev *hdev)
> >>       if (!hdev->workqueue)
> >>               goto nomem;
> >>
> >> +     hdev->tfm = alloc_cypher();
> >> +     if (IS_ERR(hdev->tfm))
> >> +             BT_INFO("Failed to load transform for ecb(aes): %ld",
> >> +                                                     PTR_ERR(hdev->tfm));
> >> +
> >>       hci_register_sysfs(hdev);
> >>
> >>       hdev->rfkill = rfkill_alloc(hdev->name, &hdev->dev,
> >> @@ -1203,6 +1219,9 @@ int hci_unregister_dev(struct hci_dev *hdev)
> >>                                       !test_bit(HCI_SETUP, &hdev->flags))
> >>               mgmt_index_removed(hdev->id);
> >>
> >> +     if (!IS_ERR(hdev->tfm))
> >> +             crypto_free_blkcipher(hdev->tfm);
> >> +
> >>       hci_notify(hdev, HCI_DEV_UNREG);
> >>
> >>       if (hdev->rfkill) {
> >> @@ -2037,3 +2056,6 @@ static void hci_cmd_task(unsigned long arg)
> >>               }
> >>       }
> >>  }
> >> +
> >> +module_param(enable_smp, bool, 0644);
> >> +MODULE_PARM_DESC(enable_smp, "Enable SMP support (LE only)");
> >
> > This all should be obviously inside smp.c
> 
> I have a couple of points against it:
> 
> 1. it's only used for one purpose, it says whether to try or not to
> allocate the block cypher, which is done during the adapter
> registration;
> 
> 2. If the current way is ok, it would mean that I would need to export
> another method from smp.c, that was something that I tried to
> minimize;
> 
> 3. and my weakest argument, seems that there are other similar uses,
> for example enable_mgmt.

A similar example here is enable_ertm inside l2cap_core.c. It's a L2CAP
related option and should reside inside L2CAP code.

> 
> But if you think the code will be clearer moving that to smp.c, will
> be glad to change.

I don't see the point on have it on hci code. SMP and Block cypher has
not much to do with HCI. I prefer it on smp.c

-- 
Gustavo F. Padovan
http://profusion.mobi

  reply	other threads:[~2011-02-28 17:28 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-21 17:23 [bluetooth-next 00/15] SMP Just Works Implementation Vinicius Costa Gomes
2011-02-21 17:23 ` [bluetooth-next 01/15] Bluetooth: Implement the first SMP commands Vinicius Costa Gomes
2011-02-21 17:23 ` [bluetooth-next 02/15] Bluetooth: Start SMP procedure Vinicius Costa Gomes
2011-02-21 17:23 ` [bluetooth-next 03/15] Bluetooth: simple SMP pairing negotiation Vinicius Costa Gomes
2011-02-21 17:23 ` [bluetooth-next 04/15] Bluetooth: Add support for using the crypto subsystem Vinicius Costa Gomes
2011-02-27 20:20   ` Gustavo F. Padovan
2011-02-28  0:49     ` Vinicius Gomes
2011-02-28 17:28       ` Gustavo F. Padovan [this message]
2011-02-28 17:40         ` Vinicius Costa Gomes
2011-03-03 17:45         ` Vinicius Costa Gomes
2011-03-09 22:52           ` Vinicius Costa Gomes
2011-03-15 19:03             ` Anderson Briglia
2011-03-15 19:12               ` Brian Gix
2011-03-24 14:14                 ` Claudio Takahasi
2011-03-24 23:07                   ` Brian Gix
2011-03-24 23:58                     ` Vinicius Costa Gomes
2011-02-21 17:23 ` [bluetooth-next 05/15] Bluetooth: LE SMP Cryptoolbox functions Vinicius Costa Gomes
2011-02-21 17:23 ` [bluetooth-next 06/15] Bluetooth: Add SMP confirmation structs Vinicius Costa Gomes
2011-02-21 17:23 ` [bluetooth-next 07/15] Bluetooth: Add SMP confirmation checks methods Vinicius Costa Gomes
2011-02-21 17:23 ` [bluetooth-next 08/15] Bluetooth: Minor fix in SMP methods Vinicius Costa Gomes
2011-02-21 17:23 ` [bluetooth-next 09/15] Bluetooth: Add support for LE Start Encryption Vinicius Costa Gomes
2011-02-21 21:52   ` [PATCH] " Vinicius Costa Gomes
2011-02-21 17:23 ` [bluetooth-next 10/15] Bluetooth: Add support for resuming socket when SMP is finished Vinicius Costa Gomes
2011-02-21 17:23 ` [bluetooth-next 11/15] Bluetooth: Fix initial security level of LE links Vinicius Costa Gomes
2011-02-21 17:23 ` [bluetooth-next 12/15] Bluetooth: Update the security level when link is encrypted Vinicius Costa Gomes
2011-02-21 17:24 ` [bluetooth-next 13/15] Bluetooth: Add support for Pairing features exchange Vinicius Costa Gomes
2011-02-21 17:24 ` [bluetooth-next 14/15] Bluetooth: Add support for SMP timeout Vinicius Costa Gomes
2011-02-21 17:24 ` [bluetooth-next 15/15] Bluetooth: Add key size checks for SMP Vinicius Costa Gomes
2011-02-25 17:21 ` [bluetooth-next 00/15] SMP Just Works Implementation Brian Gix
2011-02-25 18:19   ` Vinicius Costa Gomes
  -- strict thread matches above, loose matches on Subject: below --
2011-04-06  1:51 [bluetooth-next 00/15] SM " Vinicius Costa Gomes
2011-04-06  1:51 ` [bluetooth-next 04/15] Bluetooth: Add support for using the crypto subsystem Vinicius Costa Gomes

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110228172801.GB2165@joana \
    --to=padovan@profusion.mobi \
    --cc=anderson.briglia@openbossa.org \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=vinicius.gomes@openbossa.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).