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=-1.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED 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 D9C64C433E0 for ; Tue, 30 Jun 2020 07:56:05 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B1CC920768 for ; Tue, 30 Jun 2020 07:56:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593503765; bh=8HoL27Fy1oql9ax07Kss/tYVj+ejtEl7JwO0GZk0Q1M=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=JQIvoi5+GN1RumHt6CAzTt9zG89sE6yp4fxv9+z3vyHP3V95HJX7mA3ZU4ljdRH1N Whq/K2H9Dg0OSJglD7OszXiTIKqbj9+gk/v/3HERMV4IuNkbFxp3Z6qNMv9CrQPWEg +SPJK4BHMJG5ENBzHIHGQXGfXJp9w2XtHl6P2VUM= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730428AbgF3H4E (ORCPT ); Tue, 30 Jun 2020 03:56:04 -0400 Received: from mail.kernel.org ([198.145.29.99]:41228 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730067AbgF3Hz6 (ORCPT ); Tue, 30 Jun 2020 03:55:58 -0400 Received: from localhost (unknown [84.241.197.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id C9A882067D; Tue, 30 Jun 2020 07:55:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593503757; bh=8HoL27Fy1oql9ax07Kss/tYVj+ejtEl7JwO0GZk0Q1M=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=UseD4Oqp6Ve6uIXu8VqNQ+fkXFXjGA8IJPjriVPgrMwQ9Zccl1oDh14Xc704Qp0mQ vHxNKtxrVgK4wyg97I33ta98sFEXw5Npv+4NnGwPThG/5hMuX7Qd5JMWAVW2pDb8VT kjoJnQWVx3H+/29AWMTGhH+BQXM5ycf3tJW4hXgI= Date: Tue, 30 Jun 2020 09:55:54 +0200 From: Greg Kroah-Hartman To: Rajat Jain Cc: David Woodhouse , Lu Baolu , Joerg Roedel , Bjorn Helgaas , "Rafael J. Wysocki" , Len Brown , iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org, linux-acpi@vger.kernel.org, Raj Ashok , lalithambika.krishnakumar@intel.com, Mika Westerberg , Jean-Philippe Brucker , Prashant Malani , Benson Leung , Todd Broch , Alex Levin , Mattias Nissler , Rajat Jain , Bernie Keany , Aaron Durbin , Diego Rivas , Duncan Laurie , Furquan Shaikh , Jesse Barnes , Christian Kellner , Alex Williamson , oohall@gmail.com, Saravana Kannan , Suzuki K Poulose , Arnd Bergmann , Heikki Krogerus Subject: Re: [PATCH v2 2/7] PCI: Set "untrusted" flag for truly external devices only Message-ID: <20200630075554.GA619174@kroah.com> References: <20200630044943.3425049-1-rajatja@google.com> <20200630044943.3425049-3-rajatja@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200630044943.3425049-3-rajatja@google.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jun 29, 2020 at 09:49:38PM -0700, Rajat Jain wrote: > The "ExternalFacing" devices (root ports) are still internal devices that > sit on the internal system fabric and thus trusted. Currently they were > being marked untrusted. > > This patch uses the platform flag to identify the external facing devices > and then use it to mark any downstream devices as "untrusted". The > external-facing devices themselves are left as "trusted". This was > discussed here: https://lkml.org/lkml/2020/6/10/1049 {sigh} First off, please use lore.kernel.org links, we don't control lkml.org and it often times has been down. Also, you need to put all of the information in the changelog, referring to another place isn't always the best thing, considering you will be looking this up in 20+ years to try to figure out why people came up with such a crazy design. But, the main point is, no, we did not decide on this. "trust" is a policy decision to make by userspace, it is independant of "location", while you are tieing it directly here, which is what I explicitly said NOT to do. So again, no, I will NAK this patch as-is, sorry, you are mixing things together in a way that it should not do at this point in time. greg k-h