On Thu, Jan 17, 2013 at 07:39:15AM +0100, Takashi Iwai wrote:
At Wed, 16 Jan 2013 18:01:10 -0800, Greg KH wrote:
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 suggested.
... so are many lockdown patches, too :)
All of them in fact, which is why most of them aren't accepted upstream :)
I really 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 priority.
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 isn't 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 openSUSE kernel?
I would vote for "upstream or not".
If the condition is simply "upstream or not", I'd agree with you about openSUSE kernel inclusion. It's more maintainable to keep the openSUSE kernel close to the upstream as much as possible.
Especially given that it is updated for every release that comes out, making updating these patches a burden on the kernel maintainers. thanks, greg k-h -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org