linux-kernel - Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown

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:   Tue, 14 Nov 2017 15:31:40 -0500
From:   Matthew Garrett <mjg59@...gle.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Mimi Zohar <zohar@...ux.vnet.ibm.com>,
        David Howells <dhowells@...hat.com>,
        Alan Cox <gnomes@...rguk.ukuu.org.uk>,
        "Luis R. Rodriguez" <mcgrof@...nel.org>,
        "AKASHI, Takahiro" <takahiro.akashi@...aro.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jan Blunck <jblunck@...radead.org>,
        Julia Lawall <julia.lawall@...6.fr>,
        Marcus Meissner <meissner@...e.de>, Gary Lin <GLin@...e.com>,
        LSM List <linux-security-module@...r.kernel.org>,
        linux-efi <linux-efi@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown

On Tue, Nov 14, 2017 at 3:18 PM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> On Tue, Nov 14, 2017 at 11:58 AM, Matthew Garrett <mjg59@...gle.com> wrote:
>>
>> Our ability to determine that userland hasn't been tampered with
>> depends on the kernel being trustworthy. If userland can upload
>> arbitrary firmware to DMA-capable devices then we can no longer trust
>> the kernel. So yes, firmware is special.
>
> You're ignoring the whole "firmware is already signed by the hardware
> manufacturer and we don't even have access to it" part.

Firmware is sometimes signed by the hardware manufacturer. There's
plenty of hardware that accepts unsigned firmware.

> You're also ignoring the fact that we can't trust firmware _anyway_,
> as Alan pointed out.

Yeah, for arbitrary devices. There are cases where security has been
well audited, and it's viable to build systems where that's the
configuration you're running.

> Seriously. Some of the worst security issues have been with exactly
> the fact that we can't trust the hardware to begin with, where
> firmware/hardware combinations are not trusted to begin with.

You're right. But by that argument we might as well give up on *all*
security work - there's no way we can prove that a set of unprivileged
instructions won't backdoor a system.

> This is all theoretical security masturbation. The _real_ attacks have
> been elsewhere.

People made the same argument about Secure Boot, and then we
discovered that people *were* attacking the boot chain. As we secure
other components, the attackers move elsewhere. This is an attempt to
block off an avenue of attack before it's abused.