Received: by 2002:a05:6a10:c604:0:0:0:0 with SMTP id y4csp23884pxt; Thu, 5 Aug 2021 16:49:22 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzEa5vw7C6umbjwFcmCnrWoeVmxJn/fL4WOC3B9OTigR2WIgO79ck5HL7A3LoNW3IgWkZ5t X-Received: by 2002:a05:6638:3a12:: with SMTP id j18mr7212859jaj.75.1628207362846; Thu, 05 Aug 2021 16:49:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1628207362; cv=none; d=google.com; s=arc-20160816; b=eYgIWuWhiGOhIKEOnWKxw6FrOBX2nCyFfeUR+I2ehAu+uxLBc295UtuOCVjuJ0BJx7 /404gTdwffcOwLyj9qv5dla4ryxbetqcga9cKBN1v0pfbzItjFSMn/SmjXXlF8e9Ypox pHf1tBStMKCWBcdNcTCy9C5NmT2G+emEdP3+9dFLY6LND3O5KVQYFCRkZQyjDpGyvjBc pgD9XhfYMux4OU5B8E8e8I5hIURgRfm39PJKfxzvxhBvxoBNYviYYNF0sRH7qmcWXn7G 2kiQsctgvGdXNCbvQX8EfrCUL/6//nncnM1Uk7n9LGRzluf/HKFrrAHbe9RboTWbuQ/l 3Xhw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-language:content-transfer-encoding :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=WPJASpSvoWs/WQfuGua2WIDq4VkWCZP6prVWmJq6JPc=; b=tt5m2paZfeVdrIsTkk1oX4m8nF8hpXR+STcuaj4ftqaUZLmUAEgd+Dk3t6nqxxVqoj WCx8f3rBCTqvXLZNziAVCvEz5P9edVERgJ9D9+qMKAHRAPHxxl4YijEgRXzQ+jIx8PEh YyKw5pPI8VT3TkZuA9WEA3aQeVvr620J/DwocADdpCWXFxdfpPKj/ZlOCb8txEfHMC5G btWwx8jdBgRCeCCf4axuqH3IYX4e2pdaLRLMhX+eoK7V3WjtAjutdPkqmzBpaQozqTQJ GdNWvuv/ed7E7xX4A6S1ztpt0PsZxxMvZ68prKBMYLr8INMdVzCaMg1VUd5NwdzwUDj7 +ZkA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id t16si7640027jaq.36.2021.08.05.16.49.08; Thu, 05 Aug 2021 16:49:22 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240928AbhHER7C (ORCPT + 99 others); Thu, 5 Aug 2021 13:59:02 -0400 Received: from mga12.intel.com ([192.55.52.136]:44864 "EHLO mga12.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240920AbhHER7B (ORCPT ); Thu, 5 Aug 2021 13:59:01 -0400 X-IronPort-AV: E=McAfee;i="6200,9189,10067"; a="193810592" X-IronPort-AV: E=Sophos;i="5.84,296,1620716400"; d="scan'208";a="193810592" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Aug 2021 10:58:47 -0700 X-IronPort-AV: E=Sophos;i="5.84,296,1620716400"; d="scan'208";a="437874741" Received: from akleen-mobl1.amr.corp.intel.com (HELO [10.212.183.241]) ([10.212.183.241]) by orsmga002-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Aug 2021 10:58:46 -0700 Subject: Re: [PATCH v1] driver: base: Add driver filter support To: Greg Kroah-Hartman Cc: Kuppuswamy Sathyanarayanan , "Rafael J . Wysocki" , Jonathan Corbet , Dan Williams , Kuppuswamy Sathyanarayanan , linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org References: <20210804174322.2898409-1-sathyanarayanan.kuppuswamy@linux.intel.com> From: Andi Kleen Message-ID: <21db8884-5aa1-3971-79ef-f173a0a95bef@linux.intel.com> Date: Thu, 5 Aug 2021 10:58:46 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 8/5/2021 10:51 AM, Greg Kroah-Hartman wrote: > > It's controlled by whatever you want to use in userspace. usbguard has > been handling this logic in userspace for over a decade now just fine. So how does that work with builtin USB drivers? Do you delay the USB binding until usbguard starts up? > >> This doesn't help us handle builtin drivers that initialize before user >> space is up. > Then have the default setting for your bus be "unauthorized" like we > allow for some busses today. We need some early boot drivers, just not all of them. For example in your scheme we would need to reject all early platform drivers, which would break booting. Or allow all early platform drivers, but then we exactly get into the problem that there are far too many of them to properly harden. > There is a platform bus, it's just a fake one. The platform bus code > does the binding just like any other bus does, why is platform somehow > "special"? Except for how it is abused... For once it's usually all initialized early, so there's no way for user space to do anything. -andi