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]

Message-ID: <20171113190848.GD22894@wotan.suse.de>
Date:   Mon, 13 Nov 2017 20:08:48 +0100
From:   "Luis R. Rodriguez" <mcgrof@...nel.org>
To:     "Luis R. Rodriguez" <mcgrof@...nel.org>
Cc:     Mimi Zohar <zohar@...ux.vnet.ibm.com>,
        "AKASHI, Takahiro" <takahiro.akashi@...aro.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jan Blunck <jblunck@...radead.org>,
        Julia Lawall <julia.lawall@...6.fr>,
        David Howells <dhowells@...hat.com>,
        Andy Lutomirski <luto@...nel.org>,
        David Woodhouse <dwmw2@...radead.org>,
        Marcus Meissner <meissner@...e.de>, Gary Lin <GLin@...e.com>,
        Josh Triplett <josh@...htriplett.org>,
        Ben Hutchings <ben@...adent.org.uk>,
        Kyle McMartin <kyle@...nel.org>,
        James Bottomley <James.Bottomley@...senpartnership.com>,
        Peter Jones <pjones@...hat.com>,
        linux-security-module@...r.kernel.org, gnomes@...rguk.ukuu.org.uk,
        linux-efi <linux-efi@...r.kernel.org>,
        linux-kernel@...r.kernel.org, Matthew Garrett <mjg59@...gle.com>
Subject: Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel
 lockdown

On Mon, Nov 13, 2017 at 07:50:35PM +0100, Luis R. Rodriguez wrote:
> On Fri, Nov 10, 2017 at 08:45:06AM -0500, Mimi Zohar wrote:
> It does not mean we don't have to support hashes from the start, we can,
> however that could require a driver change where its hash is specified or
> preferred, for instance.

Actually the pseudo code I just demo'd on your RFC proposal shows how we
could support the hashes for firmware an optional first policy and if that
fails check the fw signature if present. So no driver changes would be
needed other than key'ing a respective hash for the firmware, which can
just be a macro driver addition, not an API call change.

  Luis