Received: by 2002:a05:6a10:d5a5:0:0:0:0 with SMTP id gn37csp603961pxb; Thu, 30 Sep 2021 12:53:41 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyKVzXkC421ILqvz/b1uNbWl7Fy6AsxVg2OpLID0u4+GfXIo3iYEO0z/6/Q7lg5YtVq3f47 X-Received: by 2002:a17:906:aed1:: with SMTP id me17mr1315879ejb.474.1633031620958; Thu, 30 Sep 2021 12:53:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633031620; cv=none; d=google.com; s=arc-20160816; b=bpQlkDDZeZTajpXcQ188PN0ezs9fCEX12CZ2rDvUZVGpSxld99pcEsqFUWHm2dn7Gd xnC3dIEa3xnJ5TDwz8eAFrEQGO/O9p8AlMCO6dotWTY1zsTd6xeNhlb6egOGk7DfW8nq mE5Vtt0XCkz9v0MtTpBXpjf0AfOm8Z0tC5lhJqI8Sq+mZTNwDk4t9CYfPrDa/VfQwzhh 9A43WGf7BlTvAgqCAKWP2N1hg/DkDgJlSqfUDBwOOAV0OtjurCGbNQaXBscv7RyjRO4Y e+LQkRdgoCwBeFXH0H0jx+Elb+0QhvruC0l/4kWkb6ZQZk10z11TCdHsWgb2uqHIpz/8 C+MA== 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=025NjlOfyCmyxQ+y7aGbiC8HO+xNhMWcGGK0/ih6Atw=; b=bY1DWWtYnSFHp2tlnvzzGzaiEamhQ1zVEkjVnqsbE2itKRziW7ccotZyMxPOymXyb+ j0wSQYrY/DuwT0+9lZWlsCPU4dWD8inTzaOwGD4xL1moPujHScsMdpr1pdYpUo+3DC1I 6fKmmxFgBHUxhiUUk+7eM9Vg+Ms6qCyMzLfZihzM+h2nMRtTdm2BvuVNHHei7L4Hi6u/ bxe1MEKyh81NXOwlrPLZFC16J6h7iBsgQD9r/4dl5tM7CobbLtAfp5ACkgXb/UCE92b0 dcLPgXJSRsAemz2iRv0pwXh+D5ZpX5Ojf3nyASUEFihI92RXuzEow3cE88vLY9VEn75y Wpfg== 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 f2si5471150edl.338.2021.09.30.12.53.15; Thu, 30 Sep 2021 12:53:40 -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 S1343580AbhI3TRG (ORCPT + 99 others); Thu, 30 Sep 2021 15:17:06 -0400 Received: from mga18.intel.com ([134.134.136.126]:31673 "EHLO mga18.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229652AbhI3TRB (ORCPT ); Thu, 30 Sep 2021 15:17:01 -0400 X-IronPort-AV: E=McAfee;i="6200,9189,10123"; a="212343991" X-IronPort-AV: E=Sophos;i="5.85,336,1624345200"; d="scan'208";a="212343991" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Sep 2021 12:15:17 -0700 X-IronPort-AV: E=Sophos;i="5.85,336,1624345200"; d="scan'208";a="438151438" Received: from akleen-mobl1.amr.corp.intel.com (HELO [10.252.134.229]) ([10.252.134.229]) by orsmga006-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Sep 2021 12:15:17 -0700 Subject: Re: [PATCH v2 2/6] driver core: Add common support to skip probe for un-authorized devices To: Greg Kroah-Hartman 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" References: <20210930010511.3387967-1-sathyanarayanan.kuppuswamy@linux.intel.com> <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> From: Andi Kleen Message-ID: Date: Thu, 30 Sep 2021 12:15:16 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.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 9/30/2021 10:23 AM, Greg Kroah-Hartman wrote: > On Thu, Sep 30, 2021 at 10:17:09AM -0700, Andi Kleen wrote: >>>> The "it" that I referred to is the claim that no driver should be >>>> touching hardware in their module init call. Andi seems to think >>>> such drivers are worth working around with a special remap API. >>> Andi is wrong. >> While overall it's a small percentage of the total, there are still quite a >> few drivers that do touch hardware in init functions. Sometimes for good >> reasons -- they need to do some extra probing to discover something that is >> not enumerated -- sometimes just because it's very old legacy code that >> predates the modern driver model. > Are any of them in the kernel today? > > PCI drivers should not be messing with this, we have had well over a > decade to fix that up. It's not just PCI driver, it's every driver that can do io port / MMIO / MSR / config space accesses. Maybe read the excellent article from Jon on this: https://lwn.net/Articles/865918/ > >> 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 There were also quite a few platform drivers like this. > >> 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. > >> 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. -Andi