From: "Michael S. Tsirkin" <mst@redhat.com>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Josh Boyer <jwboyer@fedoraproject.org>,
Jason Cooper <jason@lakedaemon.net>,
"ksummit-discuss@lists.linuxfoundation.org"
<ksummit-discuss@lists.linuxfoundation.org>,
James Bottomley <James.Bottomley@hansenpartnership.com>,
Mark Brown <broonie@sirena.org.uk>
Subject: Re: [Ksummit-discuss] [TOPIC] Secure/verified boot and roots of trust
Date: Wed, 3 Aug 2016 21:00:21 +0300 [thread overview]
Message-ID: <20160803203018-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <CALCETrU3E48++g2G-o4YDoazphkcVoK-gVLVHna9ZQoKVgnL5g@mail.gmail.com>
On Wed, Aug 03, 2016 at 10:23:00AM -0700, Andy Lutomirski wrote:
> >>> I don't see a compelling argument for why we'd want to do module hashing at
> >>> all, given that we have to have the signature checking mechanism around anyway
> >>> for various reasons.
> >>
> >> I think that, for the Secure Boot usecase, we actually wouldn't need
> >> the signature checking mechanism at all. Firmware signature checking
> >> in-kernel is important for some chain-of-trust use cases but AFAIK not
> >> for Secure Boot for standard desktop distros.
> >
> > Without an IOMMU you can probably subvert any DMA capable device that
> > loads unsigned firmware, at which point you're in a bad place again.
> > This isn't something I'm losing much sleep over, since attacks that
> > only work if you have a specific piece of hardware installed are much
> > less exciting. We'd still need signature checking so that users can
> > install their own signing keys, and I don't see distributions being
> > terribly enthusiastic about having two unrelated module validation
> > systems.
>
> That's a question for the distros. My intent would be to make the
> module hashing scheme as painless as possible for the distros: distros
> would just enable a config option and, if needed, adjust their debug
> info generation slightly.
It's actually nice not having to rebuild the kernel each time though.
Can the hash-checking code itself be a module (LSM?), such that hash isn't
checked if it's not loaded? One could imagine loading that
e.g. from the initrd.
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
next prev parent reply other threads:[~2016-08-03 18:00 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-03 2:58 [Ksummit-discuss] [TOPIC] Secure/verified boot and roots of trust Andy Lutomirski
2016-08-03 3:24 ` Kees Cook
2016-08-03 3:32 ` Matthew Garrett
2016-08-03 4:34 ` Andy Lutomirski
2016-08-03 4:42 ` Michael S. Tsirkin
2016-08-03 4:46 ` Andy Lutomirski
2016-08-03 5:15 ` Matthew Garrett
2016-08-03 8:33 ` Alexandre Belloni
2016-08-03 10:31 ` Mark Brown
2016-08-03 10:43 ` David Howells
2016-08-03 16:46 ` Andy Lutomirski
2016-08-03 17:17 ` Matthew Garrett
2016-08-03 17:23 ` Andy Lutomirski
2016-08-03 17:26 ` Matthew Garrett
2016-08-03 17:28 ` Andy Lutomirski
2016-08-03 18:00 ` Michael S. Tsirkin [this message]
2016-08-03 23:01 ` Ben Hutchings
2016-08-03 23:22 ` Andy Lutomirski
2016-08-04 5:26 ` Kees Cook
2016-08-17 11:38 ` Ben Hutchings
2016-08-17 13:03 ` Mimi Zohar
2016-08-17 16:11 ` Ben Hutchings
2016-08-18 12:28 ` Mimi Zohar
2016-08-03 12:42 ` James Bottomley
2016-08-03 17:04 ` Andy Lutomirski
2016-08-03 17:23 ` Matthew Garrett
2016-08-03 17:29 ` Andy Lutomirski
2016-08-03 22:09 ` James Bottomley
[not found] ` <CALCETrVpCnfOJ2aXkNsOXatQAF6NG-AcJpxeYfA9wG_t2ocykg@mail.gmail.com>
[not found] ` <CALCETrWgS0XObzxfQWQbyntVEn6QF81K2TVbS4bGNyN6EcYb_A@mail.gmail.com>
2016-08-03 22:39 ` Andy Lutomirski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160803203018-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=James.Bottomley@hansenpartnership.com \
--cc=broonie@sirena.org.uk \
--cc=jason@lakedaemon.net \
--cc=jwboyer@fedoraproject.org \
--cc=ksummit-discuss@lists.linuxfoundation.org \
--cc=luto@amacapital.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.