Received: by 2002:a05:6a10:d5a5:0:0:0:0 with SMTP id gn37csp977799pxb; Fri, 1 Oct 2021 00:04:40 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwXBdvVwEtyn/JSL0zJ1gZnBsDadCYMVqvjN057evmBMBWCaa+vLmqyS+Ua8t/DDxKXshE2 X-Received: by 2002:aa7:db52:: with SMTP id n18mr3276852edt.17.1633071879873; Fri, 01 Oct 2021 00:04:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633071879; cv=none; d=google.com; s=arc-20160816; b=p2FprlAiDfRLzqyHUzKSI2hWTE5/l9IJDa0JtxHPdZddpuOiQrTBzO0KCTwZdulwNE r6/VVhA77bXuulfnQWUFlViUXwbKjOEJMxZMsFKkMVJwJcx/r/xXpABNG3JvGGONHhce 4H1PRYdM0Hz3juoo1QUG22n12GHmel9XhJjUvrtuf9KSUhn0EN/7rxZV5MbCnFphBiGR 5DRfk4MiygYG57YTyzM2tWr4JVz7+w33RFJ/lSb89mJwmJxWvkQc3pHVc24xwqGvRj5/ DcZsIILULoggBVQbMfWKRldnk9qOpCBZcHd57Q8rEeBIPNiskdOpc8bWDUH5P+0rU+W2 dd/A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=Ci1bAR/t6eGgnwSP1MLsnTnmDosN/puwOwDKncV/WRw=; b=HMWkyXIJsGTHRuNipV+9iU9jzy2SBB2IBllg97GPx0Q3XEvgywg4/Fyxjh7OWEZ93J 2WsNtgxr1rZh/l4WuFaNr51bw1GhFGpK0zfAp5gO2/FEr9HumB1Ir/vksc6omsyQhYp1 hMkr6C56/jFKlcV6Cu0OI2XC6yuNR4XmVvkrnxQHUx1GNvbLW/R0Xrd08xeNq83z6q3N tk8Vao2clsEuaevFDNrRcLhX1ycjJa1uTVbaWeIH3mZ+57qcbOcJ1KJn/PXfenqXM3rL +M2Re9Ut39526LnuFjd9Sx4GRdSnG6qmrjIDmyuAXBC+VuLqZnt5xR1ZPNpu3sPfGN8/ ywFA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=OkPICDQR; 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=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id i18si950779ejx.16.2021.10.01.00.04.15; Fri, 01 Oct 2021 00:04:39 -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=@linuxfoundation.org header.s=korg header.b=OkPICDQR; 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=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1352177AbhJAGb0 (ORCPT + 99 others); Fri, 1 Oct 2021 02:31:26 -0400 Received: from mail.kernel.org ([198.145.29.99]:56020 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1352084AbhJAGbX (ORCPT ); Fri, 1 Oct 2021 02:31:23 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id AD0D561A57; Fri, 1 Oct 2021 06:29:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1633069779; bh=rcW5f2yBLwBChRyM5RHpwItzXk3vSZPn4evKCamc1c0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=OkPICDQRY+xltvJ7ddDOZG9kEPCfLum70sOPEt/Lf/OtCN1j2XdfJYl0kuBOqscLw PujostpRqxD/hbx2g0swIybjvlpLeo8SaUjnLXSRTOjQnHiUaGpljPKzyDUTfgD78c BZXNayCKOYFzqCEcOExF+bZMAM7SOXAsPOzEHHB0= Date: Fri, 1 Oct 2021 08:29:36 +0200 From: Greg Kroah-Hartman To: Andi Kleen Cc: "Michael S. Tsirkin" , Kuppuswamy Sathyanarayanan , Borislav Petkov , x86@kernel.org, Bjorn Helgaas , Thomas Gleixner , Ingo Molnar , Andreas Noever , Michael Jamet , Yehezkel Bernat , "Rafael J . Wysocki" , Mika Westerberg , Jonathan Corbet , Jason Wang , Dan Williams , Kuppuswamy Sathyanarayanan , linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org, linux-usb@vger.kernel.org, virtualization@lists.linux-foundation.org, "Reshetova, Elena" Subject: Re: [PATCH v2 2/6] driver core: Add common support to skip probe for un-authorized devices Message-ID: References: <20210930010511.3387967-3-sathyanarayanan.kuppuswamy@linux.intel.com> <20210930065807-mutt-send-email-mst@kernel.org> <20210930103537-mutt-send-email-mst@kernel.org> <20210930105852-mutt-send-email-mst@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Sep 30, 2021 at 12:15:16PM -0700, Andi Kleen wrote: > > On 9/30/2021 10:23 AM, Greg Kroah-Hartman wrote: > > On Thu, Sep 30, 2021 at 10:17:09AM -0700, Andi Kleen wrote: > > > The legacy drivers could be fixed, but nobody really wants to touch them > > > anymore and they're impossible to test. > > Pointers to them? > > For example if you look over old SCSI drivers in drivers/scsi/*.c there is a > substantial number that has a module init longer than just registering a > driver. As a single example look at drivers/scsi/BusLogic.c Great, send patches to fix them up instead of adding new infrastructure to the kernel. It is better to remove code than add it. You can rip the ISA code out of that driver and then you will not have the issue anymore. Or again, just add that module to the deny list and never load it from userspace. > There were also quite a few platform drivers like this. Of course, platform drivers are horrible abusers of this. Just like the recent one submitted by Intel that would bind to any machine it was loaded on and did not actually do any hardware detection assuming that it owned the platform: https://lore.kernel.org/r/20210924213157.3584061-2-david.e.box@linux.intel.com So yes, some drivers are horrible, it is our job to catch that and fix it. If you don't want to load those drivers on your system, we have userspace solutions for that (you can have allow/deny lists there.) > > > The drivers that probe something that is not enumerated in a standard way > > > have no choice, it cannot be implemented in a different way. > > PCI devices are not enumerated in a standard way??? > > The pci devices are enumerated in a standard way, but typically the driver > also needs something else outside PCI that needs some other probing > mechanism. Like what? What PCI drivers need outside connections to control the hardware? > > > So instead we're using a "firewall" the prevents these drivers from doing > > > bad things by not allowing ioremap access unless opted in, and also do some > > > filtering on the IO ports The device filter is still the primary mechanism, > > > the ioremap filtering is just belts and suspenders for those odd cases. > > That's horrible, don't try to protect the kernel from itself. Just fix > > the drivers. > > I thought we had already established this last time we discussed it. > > That's completely impractical. We cannot harden thousands of drivers, > especially since it would be all wasted work since nobody will ever need > them in virtual guests. Even if we could harden them how would such a work > be maintained long term? Using a firewall and filtering mechanism is much > saner for everyone. I agree, you can not "harden" anything here. That is why I asked you to use the existing process that explicitly moves the model to userspace where a user can say "do I want this device to be controlled by the kernel or not" which then allows you to pick and choose what drivers you want to have in your system. You need to trust devices, and not worry about trusting drivers as you yourself admit :) The kernel's trust model is that once we bind to them, we trust almost all device types almost explicitly. If you wish to change that model, that's great, but it is a much larger discussion than this tiny patchset would require. thanks, greg k-h