linux-kernel - Re: [RFC/RFT] Add noats flag to boot parameters

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:   Thu, 3 May 2018 15:15:20 -0700
From:   Nadav Amit <nadav.amit@...il.com>
To:     Sinan Kaya <okaya@...eaurora.org>
Cc:     Joerg Roedel <joro@...tes.org>, Gil Kupfer <gilkup@...il.com>,
        dwmw2@...radead.org, bhelgaas@...gle.com,
        iommu@...ts.linux-foundation.org, linux-pci@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Gil Kupfer <gilkup@...technion.ac.il>,
        Will Deacon <will.deacon@....com>,
        Bjorn Helgaas <helgaas@...nel.org>
Subject: Re: [RFC/RFT] Add noats flag to boot parameters

Sinan Kaya <okaya@...eaurora.org> wrote:

> +Bjorn,
> 
> On 5/3/2018 9:59 AM, Joerg Roedel wrote:
>> On Thu, May 03, 2018 at 09:46:34AM -0400, Sinan Kaya wrote:
>>> I also like the idea in general.
>>> Minor nit..
>>> 
>>> Shouldn't this be an iommu parameter rather than a PCI kernel command line parameter?
>>> We now have an iommu.passthrough argument that prevents page translation.
>>> 
>>> Doesn't this fit into the same category especially when it is the IOMMU drivers that
>>> call ATS functions for enablement not the PCI drivers.
>> 
>> ATS is a bit of a grey area between PCI and IOMMU, but since ATS is
>> PCI-specific and the code to enable/disable it is in PCI as well, I
>> think the parameter makes sense for PCI too.
> 
> OK. Bjorn was interested in having a command line driven feature enables in driver/pci
> directory with bitmasks for each optional PCI spec capability rather than noXYZ feature.
> 
> This would allow us to troubleshoot code breakage as well as the platform bring up to
> turn off all optional features.
> 
> Sounds like this would be a good match for that work.

I think that since this feature (ATS) has security implications, it should
be controllable through the kernel boot parameters. Otherwise, it can be
potentially too late to turn it off.

Regards,
Nadav