Received: by 2002:a25:683:0:0:0:0:0 with SMTP id 125csp773861ybg; Wed, 10 Jun 2020 13:22:05 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxg9ut7huMgrmHNsCQvr8iWALmoEy8q6KZ7s4bZKTMJKWoyddul3Zj2vryXwAPiz6IhDkpt X-Received: by 2002:a17:906:1e92:: with SMTP id e18mr5377232ejj.254.1591820525286; Wed, 10 Jun 2020 13:22:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591820525; cv=none; d=google.com; s=arc-20160816; b=W7CvNkrk52TdgSCzbZ3zJpMT7+O5x1HEuv7M8Z87nsC4X5l7IiEsxHE64TmQ1teFJ3 n7kcLumRmt9JcTNSCQVHbHlSLk70FtXjT36k/FAvo8W4fBSjscbUN/bXQ2xnc55ITdDM 18jT9NqssRFpD1faeOXFraL2IPUm6na/E1f8xMC2fnBhBfV985cbk3PI4WslVsk4QBOf wby/iugmIE6dz1pgf5RirTl4DRwtb8JfeKt2clkFbxhc3csuJvavJ1GdmJBwWmoEFFqy novfrEXdwsOxIPE9OaofMTE4AtDMBgkr7sAYeLxmfrY1dugnaVfPzo8ssBhBttA4EwZ4 h0mA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :reply-to:in-reply-to:references:mime-version:dkim-signature; bh=e7DTymW0dlvUI6UcJcAeZHCURN97Q9zDso/sHlDXRNA=; b=ed4VwPFGKZGcTB703Cu1BRrNTK7WdwDla4RXvqaeQh58bLiV2lkCopL9xZK5pxxrKH DH+pssIo9m8BGbgVaYZqa5KzgDRcVyzuZy9fG6dKiCFYaDsAxOIbSbFznuX8c/YB4tux xzbfb0Z6XkBzGuBy3bNDA4kQCYuAUruwapomQ3QrBJMbZreFdXJvmx63uu+UqpqYi2X9 VxQIqAHqNvcjsy+9Ak4/Db9PBsD+xZWRSf98DB6acHO2OXXq1lEvuBdgvn541lro8igW FjVA4fiyMfm46rytKPoaeYwaG1NO6VkJq9SIFka9bN2LFdamjZXNlSdmuRZjDNuMoqgS vA+Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b="UlN/C4YY"; 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=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id n9si669729ejz.644.2020.06.10.13.21.41; Wed, 10 Jun 2020 13:22:05 -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=@gmail.com header.s=20161025 header.b="UlN/C4YY"; 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=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728386AbgFJT5O (ORCPT + 99 others); Wed, 10 Jun 2020 15:57:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57900 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726219AbgFJT5N (ORCPT ); Wed, 10 Jun 2020 15:57:13 -0400 Received: from mail-qv1-xf43.google.com (mail-qv1-xf43.google.com [IPv6:2607:f8b0:4864:20::f43]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8B619C03E96B; Wed, 10 Jun 2020 12:57:13 -0700 (PDT) Received: by mail-qv1-xf43.google.com with SMTP id r16so1629392qvm.6; Wed, 10 Jun 2020 12:57:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=e7DTymW0dlvUI6UcJcAeZHCURN97Q9zDso/sHlDXRNA=; b=UlN/C4YYYCXVSwrKjjY3uOG/wP63W4GdE1l5KDxKe8xiggNNm3xqvFGL1N44md5YZ3 VDoCVM46iPmYU8mpemi+nbgUZcUkSqcX9UhF613wB5Dc4ooVEWBmxwKh/nY2Nh2LxKTO +RGatdPg5pWR4DsAUaN6NAlJCi1CSFPtQxcvwu/xjAEhsCZQEz9RLeeP2fJxh0EBqhGB +kdiyWBeQoDR/PHlV62/5sW+ECZc29FlXzwA6HZ6zsm052EyOd0M+IxJtSgJGxf6lAmY lvYyXgBsMdZAm5Dirf2hxBmO6X2rkG5BWZ++xB1Ur6VG2KGpfVVmwvQp7bGTgGAqXoYA /hFg== 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:reply-to :from:date:message-id:subject:to:cc; bh=e7DTymW0dlvUI6UcJcAeZHCURN97Q9zDso/sHlDXRNA=; b=nq43tVZjOyvOxhQe+9rg++T1R51PCLx0kHXZa4aylhiGvpTtiiAY0/pNpT4BOlPNqp Yz9Ue8NTACSKeD5u2l8wysQOvie9qeavnTNqmnWGt8rZsN+9Jc0cXLxSN+VdkNMewTHK 33XZOJPvnSYVORwXWM9MORnwFBZ41nqhyjO7a+8PsquBpyAMHPknkaCmBp5ZvJgR8X8c r1YQWcmKHOop2kazLzcEKQ8bqOc+6HPBpNLjYU39lYsrHzSYZdcMwE7w3Vlf9x/Ttxn0 yDuOlxp5iPbAuektjQKo4gpt3x2QV5YW8jJGOP3b4ydiC/c2LxpjBod37hnskja1JQcv KxlQ== X-Gm-Message-State: AOAM533KhHC5EpTklGl9TZxcBIIVNSp496gXhSEZeu06KR0a2DjtL80M 8I156piwxcf1rMNHR/+b0CEYME8xqP7iDJ3V9WzBd54mdOU= X-Received: by 2002:ad4:4627:: with SMTP id x7mr3830646qvv.54.1591819032442; Wed, 10 Jun 2020 12:57:12 -0700 (PDT) MIME-Version: 1.0 References: <20200607113632.GA49147@kroah.com> <20200609210400.GA1461839@bjorn-Precision-5520> In-Reply-To: Reply-To: rajatxjain@gmail.com From: Rajat Jain Date: Wed, 10 Jun 2020 12:57:00 -0700 Message-ID: Subject: Re: [RFC] Restrict the untrusted devices, to bind to only a set of "whitelisted" drivers To: "Oliver O'Halloran" Cc: Bjorn Helgaas , Greg Kroah-Hartman , Rajat Jain , "Raj, Ashok" , "Krishnakumar, Lalithambika" , Bjorn Helgaas , linux-pci , Mika Westerberg , Jean-Philippe Brucker , Prashant Malani , Benson Leung , Todd Broch , Alex Levin , Mattias Nissler , Zubin Mithra , Bernie Keany , Aaron Durbin , Diego Rivas , Duncan Laurie , Furquan Shaikh , Jesse Barnes , Christian Kellner , Alex Williamson , Joerg Roedel , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 9, 2020 at 6:34 PM Oliver O'Halloran wrote: > > On Wed, Jun 10, 2020 at 7:04 AM Bjorn Helgaas wrote: > > > > To sketch this out, my understanding of how this would work is: > > > > - Expose the PCI pdev->untrusted bit in sysfs. We don't expose this > > today, but doing so would be trivial. I think I would prefer a > > sysfs name like "external" so it's more descriptive and less of a > > judgment. > > > > This comes from either the DT "external-facing" property or the > > ACPI "ExternalFacingPort" property. > > I don't think internal / external is the right distinction to be > making. We have a similar trust issue with the BMC in servers even > though they're internal devices. They're typically network accessible > and infrequently updated so treating them as trustworthy isn't a great > idea. We have been slowly de-privileging the BMC over the last few > years, but the PCIe interface isn't locked down enough for my liking > since the SoCs we use do allow software to set the VDID and perform > arbitrary DMAs (thankfully limited to 32bit). If we're going to add in > infrastructure for handling possibly untrustworthy PCI devices then > I'd like to use that for BMCs too. > > > - All devices present at boot are enumerated. Any statically built > > drivers will bind to them before any userspace code runs. > > > > If you want to keep statically built drivers from binding, you'd > > need to invent some mechanism so pci_driver_init() could clear > > drivers_autoprobe after registering pci_bus_type. > > > > - Early userspace code prevents modular drivers from automatically > > binding to PCI devices: > > > > echo 0 > /sys/bus/pci/drivers_autoprobe > > > > This prevents modular drivers from binding to all devices, whether > > present at boot or hot-added. > > I don't see why this is preferable to just disabling autoprobe for > untrusted devices. That would dovetail nicely with Rajat's whitelist > idea if we want to go down that route and I think we might want to. > The BMC usually provides some form of VGA console and we'd like that > to continue working out-of-the-box without too much user (or distro) > intervention. I wouldn't mind introducing a kernel parameter to disable auto-probing of untrusted devices if there is a wider agreement here. The only notch is that in my opinion, if present, that parameter should disable auto-probing for "external" devices only (i.e. "external-facing" devices should still be auto-probed). Thanks, Rajat > > Oliver