linux-kernel - Re: [PATCH v2 1/3] platform/x86: Add Intel Input Output Manager (IOM) driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 28 Aug 2020 12:08:32 +0300
From:   Heikki Krogerus <heikki.krogerus@...ux.intel.com>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Rajmohan Mani <rajmohan.mani@...el.com>,
        Darren Hart <dvhart@...radead.org>,
        Andy Shevchenko <andy@...radead.org>,
        Mika Westerberg <mika.westerberg@...ux.intel.com>,
        Dmitry Torokhov <dmitry.torokhov@...il.com>,
        Lee Jones <lee.jones@...aro.org>,
        Ayman Bagabas <ayman.bagabas@...il.com>,
        Masahiro Yamada <masahiroy@...nel.org>,
        Jithu Joseph <jithu.joseph@...el.com>,
        Blaž Hrastnik <blaz@...n.io>,
        Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>,
        linux-kernel@...r.kernel.org, platform-driver-x86@...r.kernel.org,
        linux-usb@...r.kernel.org, pmalani@...omium.org,
        bleung@...omium.org
Subject: Re: [PATCH v2 1/3] platform/x86: Add Intel Input Output Manager
 (IOM) driver

Hi Greg,

On Fri, Aug 28, 2020 at 09:43:59AM +0200, Greg Kroah-Hartman wrote:
> I still find this crazy that a whole separate driver is created just to
> read a single 32bit value.
> 
> Why not put this logic in the driver that wants to read that value?
> That would be much simpler, smaller, and more obvious.

That would mean that we start maintaining something like DMI quirk
table in those drivers. Unfortunately the IOM device is not available
on every platform. Also, even on platforms that do have it, there is
no guarantee that the device is always going to be mapped to the same
address.

Nevertheless, I was originally hoping that we could hide the handling
of IOM somehow in ACPI without the need for an actual device object,
but it now turns out that the other features of the IOM chip have
created interest. At least our i915 guys probable have some use for it
(I don't know exactly what they are planning to use it for).

So the fact that we may later need the device for something else, on
top of the clumsiness and most importantly risks involved with using
ACPI to take care of extra tasks (ASL tends to have bugs - bugs that
may never ever get fixed), I think the IOM device object, and the
driver that binds to it, do have a valid reason for existing.

thanks,

-- 
heikki