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:   Sun, 10 Oct 2021 15:22:39 -0700
From:   Andi Kleen <>
To:     "Michael S. Tsirkin" <>,
        Kuppuswamy Sathyanarayanan 
Cc:     Thomas Gleixner <>,
        Ingo Molnar <>, Borislav Petkov <>,
        Peter Zijlstra <>,
        Andy Lutomirski <>,
        Bjorn Helgaas <>,
        Richard Henderson <>,
        Thomas Bogendoerfer <>,
        James E J Bottomley <>,
        Helge Deller <>,
        "David S . Miller" <>,
        Arnd Bergmann <>,
        Jonathan Corbet <>,
        Paolo Bonzini <>,
        David Hildenbrand <>,
        Andrea Arcangeli <>,
        Josh Poimboeuf <>,
        Peter H Anvin <>,
        Dave Hansen <>,
        Tony Luck <>,
        Dan Williams <>,
        Kirill Shutemov <>,
        Sean Christopherson <>,
        Kuppuswamy Sathyanarayanan <>,,,,,,,,,,
Subject: Re: [PATCH v5 12/16] PCI: Add pci_iomap_host_shared(),

> To which Andi replied
> 	One problem with removing the ioremap opt-in is that
> 	it's still possible for drivers to get at devices without going through probe.
> To which Greg replied:
> 	If there are in-kernel PCI drivers that do not do this, they need to be
> 	fixed today.
> Can you guys resolve the differences here?

I addressed this in my other mail, but we may need more discussion.

> And once they are resolved, mention this in the commit log so
> I don't get to re-read the series just to find out nothing
> changed in this respect?
> I frankly do not believe we are anywhere near being able to harden
> an arbitrary kernel config against attack.

Why not? Device filter and the opt-ins together are a fairly strong 

And it's not that they're a lot of code or super complicated either.

You're essentially objecting to a single line change in your subsystem here.

> How about creating a defconfig that makes sense for TDX then?

TDX can be used in many different ways, I don't think a defconfig is 

In theory you could do some Kconfig dependency (at the pain point of 
having separate kernel binariees), but why not just do it at run time 
then if you maintain the list anyways. That's much easier and saner for 
everyone. In the past we usually always ended up with runtime mechanism 
for similar things anyways.

Also it turns out that the filter mechanisms are needed for some arch 
drivers which are not even configurable, so alone it's probably not enough,

> Anyone deviating from that better know what they are doing,
> this API tweaking is just putting policy into the kernel  ...

Hardening drivers is kernel policy. It cannot be done anywhere else.


Powered by blists - more mailing lists