linux-kernel - Re: [PATCH 6/7] x86/boot/tboot: Move tboot_force

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:   Wed, 18 May 2022 15:38:08 +0800
From:   Baolu Lu <baolu.lu@...ux.intel.com>
To:     Jason Gunthorpe <jgg@...dia.com>
Cc:     baolu.lu@...ux.intel.com, Joerg Roedel <joro@...tes.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Paolo Bonzini <pbonzini@...hat.com>,
        David Airlie <airlied@...ux.ie>,
        Jani Nikula <jani.nikula@...ux.intel.com>,
        Joonas Lahtinen <joonas.lahtinen@...ux.intel.com>,
        Rodrigo Vivi <rodrigo.vivi@...el.com>,
        Tvrtko Ursulin <tvrtko.ursulin@...ux.intel.com>,
        Daniel Vetter <daniel@...ll.ch>,
        Kevin Tian <kevin.tian@...el.com>,
        Ashok Raj <ashok.raj@...el.com>, Liu Yi L <yi.l.liu@...el.com>,
        Jacob Pan <jacob.jun.pan@...ux.intel.com>,
        Ning Sun <ning.sun@...el.com>, Will Deacon <will@...nel.org>,
        Robin Murphy <robin.murphy@....com>,
        Christoph Hellwig <hch@....de>,
        Steve Wahl <steve.wahl@....com>,
        iommu@...ts.linux-foundation.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 6/7] x86/boot/tboot: Move tboot_force_iommu() to Intel
 IOMMU

On 2022/5/17 19:13, Jason Gunthorpe wrote:
> On Tue, May 17, 2022 at 10:05:43AM +0800, Baolu Lu wrote:
>> Hi Jason,
>>
>> On 2022/5/17 02:06, Jason Gunthorpe wrote:
>>>> +static __init int tboot_force_iommu(void)
>>>> +{
>>>> +	if (!tboot_enabled())
>>>> +		return 0;
>>>> +
>>>> +	if (no_iommu || dmar_disabled)
>>>> +		pr_warn("Forcing Intel-IOMMU to enabled\n");
>>> Unrelated, but when we are in the special secure IOMMU modes, do we
>>> force ATS off? Specifically does the IOMMU reject TLPs that are marked
>>> as translated?
>>
>> Good question. From IOMMU point of view, I don't see a point to force
>> ATS off, but trust boot involves lots of other things that I am not
>> familiar with. Anybody else could help to answer?
> 
> ATS is inherently not secure, if a rouge device can issue a TLP with
> the translated bit set then it has unlimited access to host memory.

Agreed. The current logic is that the platform lets the OS know such
devices through firmware (ACPI/DT) and OS sets the untrusted flag in
their device structures. The IOMMU subsystem will disable ATS on devices
with the untrusted flag set.

There is some discussion about allowing the supervisor users to set the
trust policy through the sysfs ABI, but I don't think this has happened
in upstream kernel.

> Many of these trusted iommu scenarios rely on the idea that a rouge
> device cannot DMA to arbitary system memory.

I am not sure whether tboot has the same requirement.

Best regards,
baolu