From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-14.6 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A7A72C433E1 for ; Fri, 17 Jul 2020 13:18:06 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 849962076D for ; Fri, 17 Jul 2020 13:18:06 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="sf/T5sXR" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726848AbgGQNSE (ORCPT ); Fri, 17 Jul 2020 09:18:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:32966 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726316AbgGQNSD (ORCPT ); Fri, 17 Jul 2020 09:18:03 -0400 Received: from mail-lj1-x243.google.com (mail-lj1-x243.google.com [IPv6:2a00:1450:4864:20::243]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 11476C08C5CE for ; Fri, 17 Jul 2020 06:18:03 -0700 (PDT) Received: by mail-lj1-x243.google.com with SMTP id h19so12534448ljg.13 for ; Fri, 17 Jul 2020 06:18:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=YM/u3gjvM4q2JWx7UhekKDRsr2AbTo4qfrXy3xVIS9k=; b=sf/T5sXRhkN8YEk+EOhFcH7el1N/kDRdyYraixUm9LORleyvBRdP8ykec29CpkXDZ0 XdWo4qDS1Eb3DhdzVwzo3n7xUQVm7CNj//prYhxniDyOhmZgnDxQq2loH/Q1zmNqNpw1 lB8Qmjes7B8dWb1K+U5rZm9CwsCECVIpnOt3TWQ8DL4f4muqq9Bsc8cf06KfSeuQYX50 2IbpMhKO+GSpgked7oB5bNy8GmbF/7mxtbN+DMyEhnj92oIcfQPJ53kNUUSYjZMYWn8V FX0kTIWd/AuJ37dNa7Ivap7Qnqg8eIGtZoFy5rLiFsUVU4H+aiD9jnatv4aor2jp97pk MGKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=YM/u3gjvM4q2JWx7UhekKDRsr2AbTo4qfrXy3xVIS9k=; b=K9+BLaEtZkEHaSnoMZ8TjiToVetnk4fKOVP48eitTDqSVmCnvrE4p8+wnugiRTaMkx Ut76zbMQC9wBfkRaUYe85mx5VAJr6W9g6r/wXE8wmAo0xVRmOG7zzOqQq6QQZ+bdHtgy 7pkRaxPBAiw3/M8hyrSP5XaY6VDlR5uWkhSNMSWAH38Qt8EgddOzCf64KHTKw9Gu0NgY GZR7t11MDlZs2aqEaDKWgNfjC+DdjblL0dInO/fJx54tKuspdt2fXf1FAx/+/KLx0nIN vHq+Nt44dRa+f5atSVkLsVS5wbXQ1ScLfpvD06VRX9BxalFF1SXD21MSMzMOdgcPPtDt 8slQ== X-Gm-Message-State: AOAM530DB5jJ3AEDboBJObO4PIqplGVo4X+7dXDnOBj7LJm4uDifp5Jv 1PZ71BKa+Y725iKCwnKUOkhiW1a8Bo8iQ5VHOsABaA== X-Google-Smtp-Source: ABdhPJzyiKZ2NKZx86wa+HGnmDvLl67Vrz1HhWzCdoYhwu2nhGboSac3BbZ6dVMwxJ5PgjdsgB9Ac7A5V093fgDDewk= X-Received: by 2002:a2e:910c:: with SMTP id m12mr4340344ljg.274.1594991881148; Fri, 17 Jul 2020 06:18:01 -0700 (PDT) MIME-Version: 1.0 References: <20200627105437.453053-1-apusaka@google.com> <20200627185320.RFC.v1.1.Icea550bb064a24b89f2217cf19e35b4480a31afd@changeid> <91CFE951-262A-4E83-8550-25445AE84B5A@holtmann.org> <7BBB55E0-FBD9-40C0-80D9-D5E7FC9F80D2@holtmann.org> In-Reply-To: From: Alain Michaud Date: Fri, 17 Jul 2020 09:17:49 -0400 Message-ID: Subject: Re: [RFC PATCH v1 1/2] Bluetooth: queue ACL packets if no handle is found To: Marcel Holtmann Cc: Archie Pusaka , linux-bluetooth , chromeos-bluetooth-upstreaming , Abhishek Pandit-Subedi , "David S. Miller" , Jakub Kicinski , Johan Hedberg , kernel list , netdev Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-bluetooth-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-bluetooth@vger.kernel.org Hi Marcel, On Fri, Jul 17, 2020 at 2:51 AM Marcel Holtmann wrote= : > > Hi Alain, > > > >>> There is a possibility that an ACL packet is received before we > > >>> receive the HCI connect event for the corresponding handle. If this > > >>> happens, we discard the ACL packet. > > >>> > > >>> Rather than just ignoring them, this patch provides a queue for > > >>> incoming ACL packet without a handle. The queue is processed when > > >>> receiving a HCI connection event. If 2 seconds elapsed without > > >>> receiving the HCI connection event, assume something bad happened > > >>> and discard the queued packet. > > >>> > > >>> Signed-off-by: Archie Pusaka > > >>> Reviewed-by: Abhishek Pandit-Subedi > > >> > > >> so two things up front. I want to hide this behind a HCI_QUIRK_OUT_O= F_ORDER_ACL that a transport driver has to set first. Frankly if this kind = of out-of-order happens on UART or SDIO transports, then something is obvio= usly going wrong. I have no plan to fix up after a fully serialized transpo= rt. > > >> > > >> Secondly, if a transport sets HCI_QUIRK_OUT_OF_ORDER_ACL, then I wan= t this off by default. You can enable it via an experimental setting. The r= eason here is that we have to make it really hard and fail as often as poss= ible so that hardware manufactures and spec writers realize that something = is fundamentally broken here. > > I don't have any objection to making this explicit enable to non serial= ized transports. However, I do wonder what the intention is around making = this off by default. We already know there is a race condition between the= interupt and bulk endpoints over USB, so this can and does happen. Hardwa= re manufaturers can't relly do much about this other than trying to pull th= e interupt endpoint more often, but that's only a workaround, it can't avoi= d it all together. > > > > IMO, this seems like a legitimate fix at the host level and I don't see= any obvious benefits to hide this fix under an experimental feature and ma= ke it more difficult for the customers and system integrators to discover. > > the problem is that this is not a fix. It is papering over a hole and at = best a workaround with both eyes closed and hoping for the best. I am not l= ooking forward for the first security researcher to figure out that they ha= ve a chance to inject an unencrypted packet since we are waiting 2 seconds = for the USB transport to get its act together. I don't think this is the right characterization but I agree, 2 seconds would be too long, it would ideally be no longer than the USB polling interval diff. > > In addition, I think that Luiz attempt to align with the poll intervals i= nside the USB transport directly is a cleaner and more self-contained appro= ach. It also reduces the window of opportunity for any attacker since we ac= tually align the USB transport specific intervals with each other. I'll have to look at Luiz's patch and think through if this really eliminates the problem. If may indeed be a more practical approach to this problem. > > Regards > > Marcel >