Received: by 2002:a05:6a10:d5a5:0:0:0:0 with SMTP id gn37csp1467805pxb; Fri, 1 Oct 2021 11:12:51 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwRhyksX4977CVCbwSQ1Ie/P65m7L4sUjMRTQEUmckv5KTyPjv+AlsgmFirX7wnz6ZLDura X-Received: by 2002:a05:6a00:14d2:b0:44c:b33:984b with SMTP id w18-20020a056a0014d200b0044c0b33984bmr7099548pfu.23.1633111971597; Fri, 01 Oct 2021 11:12:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633111971; cv=none; d=google.com; s=arc-20160816; b=Pbkf3SQ6ljS+3qMd9po41LwhbkaDlnG1aj9zo2Mbcyz8sCwYiHUJAFRUMwQ1eenTSB pkgYrbDZiZexZvJVLo3bb1wVkQYM+lmUcBAJekftLx12fMbwP+qKAb0d+nB+BvYhNPMp h4hl30SRGh2gTr8dF+GOWOmPx25I8EkfuLuAAayC76GO4DpvILmYnRrHwnP41M5YJv0o 1HCKSIKa+6gc+/J7gD1SjflArnybeX/ealqXYVThSZhaE+owHRUfdMsRGGmLsJE8Jle1 ILOkfgK7h8bdmGHSBXwvn64lrM2u8TyEtgq7NpI30XEqBGff11Jfpm+wW3VG5Q9wDhDz mwWQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=2KFuOrTMhH3SQsw1rM/3FEXg4ao/BGYA5Ilqe0th6JM=; b=DkR8pPyrYcIkUOI6OdM41g2RuW50R1ZXGuybVrDcVJIbkMCvvFxoWR7qmXu9qSBqaA I94vMJAnAVuK/2vFHCWJJprzQ+4DG6Bn0dJCZYWii3VrN5a1i6Tgfw5/xEosHdHrmMUn 0aLppzBLE8POP6lfdncEXicKzBTsQMxF4A+BaptX7ZZxYcNdq0zWp9IlTfyXi5nV+JcH G7Txzk89TAtxszrCXYohefJyxO+tDd2xgxeK1VLNRbJ4B3PNa8gOHuQZ6gpvqVBlGnIr CT9dCAcdWfpJQdSi0sHsBUUoESbkz7KwyBcIwJe+mybX2DG0wxXkQ/mtoNBrDNOitwI9 CJxA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel-com.20210112.gappssmtp.com header.s=20210112 header.b=NDbfA3Xj; 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 h128si8356987pfb.155.2021.10.01.11.12.30; Fri, 01 Oct 2021 11:12:51 -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; dkim=pass header.i=@intel-com.20210112.gappssmtp.com header.s=20210112 header.b=NDbfA3Xj; 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 S229576AbhJASLy (ORCPT + 99 others); Fri, 1 Oct 2021 14:11:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49574 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238784AbhJASLr (ORCPT ); Fri, 1 Oct 2021 14:11:47 -0400 Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4B948C06177E for ; Fri, 1 Oct 2021 11:10:03 -0700 (PDT) Received: by mail-pl1-x62f.google.com with SMTP id y5so6838371pll.3 for ; Fri, 01 Oct 2021 11:10:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2KFuOrTMhH3SQsw1rM/3FEXg4ao/BGYA5Ilqe0th6JM=; b=NDbfA3XjG5EhuNjh+dRar041dNJzw1gWHW6t+j97IW2pEjdJSk+YfuCAkrm4fDmjkO 0pVPJaITMLoKmUdk6x7lCcT+oIBj+ETmUCSbdmpCdzHtL5l7zoz7tIvrGEfpKbPxiIYu /+P6IplqX3kirO8xwKxQmGhFDwpB3qeScSFXJVTc2it/D+aS3MMDemWs535izc/INWUw nUzYVdFPjGWsRtC7OdTOPI5KlsLMhNqOMT55cuSSJ3jFhvPS84t3GqwTqBxu514MA6C1 M425dYCXlqS0TK5NPkHcYAR+SwVvSNx3oDZqFPnKdEA9d5B8B2pAY67LX+y0krOYYvOx +gRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2KFuOrTMhH3SQsw1rM/3FEXg4ao/BGYA5Ilqe0th6JM=; b=MQd2QBphLSaSq3vkHsVL18KphGWIwq3NYSwz7OzNGU6MHO2bUBd7znS+I9LZhwGQNN D0lSEryQSZpP8dafEDoVCweVFMLp8IqbXnxfWZZ+Z8Dp/wCZE6hlgRSOhMF+9EeffG/w nHl/m7sIZEpsYJyH3NPW8AWwrtO1c5pzRl1l1U4KUW+h6ffahutC3sXCnfywvekNoM/+ U59rb1RfiRey/5v9EWF2Y2mXrztCUBk0NjCVF5KPvsLc0oJLCo3CaSfidadsZZX42WMN Jf58MKedF2U8PgWH+xjU+yokCPoKInc9B4l1fXZgqPJi6BFEr4kJi5i7smAmrlpKcDBT m6uQ== X-Gm-Message-State: AOAM533ce/syPwduqJoDv66AuD/hUHXdQ4id70Qmgp/Hg8uO1/hcie2X KRgPW2bvg/OtWdnnapC6OHtQWmHr0C5hlS03oLJagQ== X-Received: by 2002:a17:90b:3b84:: with SMTP id pc4mr14704315pjb.220.1633111802704; Fri, 01 Oct 2021 11:10:02 -0700 (PDT) MIME-Version: 1.0 References: <20210930010511.3387967-1-sathyanarayanan.kuppuswamy@linux.intel.com> <20210930010511.3387967-5-sathyanarayanan.kuppuswamy@linux.intel.com> <20210930065953-mutt-send-email-mst@kernel.org> <6d1e2701-5095-d110-3b0a-2697abd0c489@linux.intel.com> <1cfdce51-6bb4-f7af-a86b-5854b6737253@linux.intel.com> <20211001164533.GC505557@rowland.harvard.edu> In-Reply-To: <20211001164533.GC505557@rowland.harvard.edu> From: Dan Williams Date: Fri, 1 Oct 2021 11:09:52 -0700 Message-ID: Subject: Re: [PATCH v2 4/6] virtio: Initialize authorized attribute for confidential guest To: Alan Stern Cc: Greg Kroah-Hartman , "Kuppuswamy, Sathyanarayanan" , "Michael S. Tsirkin" , Borislav Petkov , X86 ML , Bjorn Helgaas , Thomas Gleixner , Ingo Molnar , Andreas Noever , Michael Jamet , Yehezkel Bernat , "Rafael J . Wysocki" , Mika Westerberg , Jonathan Corbet , Jason Wang , Andi Kleen , Kuppuswamy Sathyanarayanan , Linux Kernel Mailing List , Linux PCI , USB list , virtualization@lists.linux-foundation.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 1, 2021 at 9:47 AM Alan Stern wrote: > > On Fri, Oct 01, 2021 at 09:13:54AM -0700, Dan Williams wrote: > > Bear with me, and perhaps it's a lack of imagination on my part, but I > > don't see how to get to a globally generic "authorized" sysfs ABI > > given that USB and Thunderbolt want to do bus specific actions on > > authorization toggle events. Certainly a default generic authorized > > attribute can be defined for all the other buses that don't have > > legacy here, but Thunderbolt will still require support for '2' as an > > authorized value, and USB will still want to base probe decisions on > > the authorization state of both the usb_device and the usb_interface. > > The USB part isn't really accurate (I can't speak for Thunderbolt). > When a usb_device is deauthorized, the device will be unconfigured, > deleting all its interfaces and removing the need for any probe > decisions about them. In other words, the probe decision for a > usb_device or usb_interface depends only on the device's/interface's > own authorization state. > > True, the interface binding code does contain a test of the device's > authorization setting. That test is redundant and can be removed. > > The actions that USB wants to take on authorization toggle events for > usb_devices are: for authorize, select and install a configuration; > for deauthorize, unconfigure the device. Each of these could be > handled simply enough just by binding/unbinding the device. (There > is some special code for handling wireless USB devices, but wireless > USB is now defunct.) Ah, so are you saying that it would be sufficient for USB if the generic authorized implementation did something like: dev->authorized = 1; device_attach(dev); ...for the authorize case, and: dev->authorize = 0; device_release_driver(dev); ...for the deauthorize case?