linux-kernel - Re: [PATCH] iommu: Add support to filter non-strict/lazy mode based on device names

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]

Message-ID: <f8ac8f57bcf10b2218b4795197efb854@codeaurora.org>
Date:   Wed, 26 Aug 2020 20:31:03 +0530
From:   Sai Prakash Ranjan <saiprakash.ranjan@...eaurora.org>
To:     Robin Murphy <robin.murphy@....com>
Cc:     Douglas Anderson <dianders@...omium.org>,
        Will Deacon <will@...nel.org>, Joerg Roedel <joro@...tes.org>,
        Tomasz Figa <tfiga@...omium.org>,
        Stephen Boyd <swboyd@...omium.org>,
        iommu@...ts.linux-foundation.org,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        linux-arm-msm@...r.kernel.org
Subject: Re: [PATCH] iommu: Add support to filter non-strict/lazy mode based
 on device names

On 2020-08-26 19:21, Robin Murphy wrote:
> On 2020-08-26 13:17, Sai Prakash Ranjan wrote:
>> On 2020-08-26 17:07, Robin Murphy wrote:
>>> On 2020-08-25 16:42, Sai Prakash Ranjan wrote:
>>>> Currently the non-strict or lazy mode of TLB invalidation can only 
>>>> be set
>>>> for all or no domains. This works well for development platforms 
>>>> where
>>>> setting to non-strict/lazy mode is fine for performance reasons but 
>>>> on
>>>> production devices, we need a more fine grained control to allow 
>>>> only
>>>> certain peripherals to support this mode where we can be sure that 
>>>> it is
>>>> safe. So add support to filter non-strict/lazy mode based on the 
>>>> device
>>>> names that are passed via cmdline parameter 
>>>> "iommu.nonstrict_device".
>>> 
>>> There seems to be considerable overlap here with both the existing
>>> patches for per-device default domain control [1], and the broader
>>> ongoing development on how to define, evaluate and handle "trusted"
>>> vs. "untrusted" devices (e.g. [2],[3]). I'd rather see work done to
>>> make sure those integrate properly together and work well for
>>> everyone's purposes, than add more disjoint mechanisms that only
>>> address small pieces of the overall issue.
>>> 
>>> Robin.
>>> 
>>> [1]
>>> https://lore.kernel.org/linux-iommu/20200824051726.7xaJRTTszJuzdFWGJ8YNsshCtfNR0BNeMrlILAyqt_0@z/ 
>>> [2]
>>> https://lore.kernel.org/linux-iommu/20200630044943.3425049-1-rajatja@google.com/ 
>>> [3]
>>> https://lore.kernel.org/linux-iommu/20200626002710.110200-2-rajatja@google.com/
>> 
>> Thanks for the links, [1] definitely sounds interesting, I was under 
>> the impression
>> that changing such via sysfs is late, but seems like other Sai has got 
>> it working
>> for the default domain type. So we can extend that and add a strict 
>> attribute as well,
>> we should be definitely OK with system booting with default strict 
>> mode for all
>> peripherals as long as we have an option to change that later, Doug?
> 
> Right, IIRC there was initially a proposal of a command line option
> there too, and it faced the same criticism around not being very
> generic or scalable. I believe sysfs works as a reasonable compromise
> since in many cases it can be tweaked relatively early from an initrd,
> and non-essential devices can effectively be switched at any time by
> removing and reprobing their driver.
> 

Ah I see, so the catch is that device must not be bound to the driver
and won't work for the internal devices or builtin drivers probed early.

-Sai

> As for a general approach for internal devices where you do believe
> the hardware is honest but don't necessarily trust whatever firmware
> it happens to be running, I'm pretty sure that's come up already, but
> I'll be sure to mention it at Rajat's imminent LPC talk if nobody else
> does.
> 
> Robin.


-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member
of Code Aurora Forum, hosted by The Linux Foundation