On Wed, Jan 16, 2013 at 09:24:20AM +0100, Takashi Iwai wrote:
At Tue, 15 Jan 2013 23:55:02 -0800,
Greg KH wrote:
On Wed, Jan 16, 2013 at 03:44:02PM +0800, joeyli wrote:
> 於 二，2013-01-15 於 23:10 -0800，Greg KH 提到：
> > On Wed, Jan 16, 2013 at 02:49:34PM +0800, Lee, Chun-Yi wrote:
> > > Patch-mainline: Not yet, reviewing (contributed by Takashi)
> > > Target: openSUSE 12.3
> > Why do we want to add this feature to 12.3 when it isn't needed by
> > anyone? And it's not accepted upstream either.
> > thanks,
> > greg k-h
> The purpose of this patch set is for sign driver firmware to avoid
> attacker change the firmware to attack system. Takashi sent patches to
> upstream for ask other experts' thinking.
> But, yes, upstream didn't accept it until now.
Now? I don't see them in Linus's tree, do you?
And all firmware should already be signed, you are trying to extend the
chain-of-trust to a different processor on the system, which is _way_
beyond what UEFI is asking for, and beyond anything that anyone has ever
... so are many lockdown patches, too :)
All of them in fact, which is why most of them aren't accepted upstream :)
don't think these are necessary, does anyone else?
Well, when this issue was discussed on ML, people (e.g. mjg) agreed
that this would be a thing good-to-have, but certainly in a low
Whether to mandate this in secure boot mode is still an open
question, I myself am not sure, too. But, one strong argument is that
the CPU microcode is handled as a normal firmware file on Linux, thus
it can be an attack vector.
(And apart from that, having a capability for checking the validity of
firmware files is a benefit, too.)
Sure, it's a "nice" feature, but why add it to openSUSE when it
accepted upstream and no one is asking for it?
OK, what about the other lockdown patches? From your standpoint,
should they (the ones that aren't in upstream) be neither included to