On Sat, 2012-10-20 at 08:15 +0800, joeyli wrote:
> Hi Matt,
>
> Sorry for bother you!
>
> I didn't see this Matthew's patchset merged in EFI git tree. Do you have
> plan to merge it? Or those patches need wait different subsystem leaders
> merge.
I don't think it makes sense for the secure
On Sat, 2012-10-20 at 08:15 +0800, joeyli wrote:
Hi Matt,
Sorry for bother you!
I didn't see this Matthew's patchset merged in EFI git tree. Do you have
plan to merge it? Or those patches need wait different subsystem leaders
merge.
I don't think it makes sense for the secure boot patch
Hi Matt,
Sorry for bother you!
I didn't see this Matthew's patchset merged in EFI git tree. Do you have
plan to merge it? Or those patches need wait different subsystem leaders
merge.
Thanks a lot!
Joey Lee
於 四,2012-09-20 於 10:40 -0400,Matthew Garrett 提到:
> Secure boot adds certain policy
Hi Matt,
Sorry for bother you!
I didn't see this Matthew's patchset merged in EFI git tree. Do you have
plan to merge it? Or those patches need wait different subsystem leaders
merge.
Thanks a lot!
Joey Lee
於 四,2012-09-20 於 10:40 -0400,Matthew Garrett 提到:
Secure boot adds certain policy
Quoting Matthew Garrett (m...@redhat.com):
> Secure boot adds certain policy requirements, including that root must not
> be able to do anything that could cause the kernel to execute arbitrary code.
> The simplest way to handle this would seem to be to add a new capability
> and gate various
Quoting Matthew Garrett (m...@redhat.com):
Secure boot adds certain policy requirements, including that root must not
be able to do anything that could cause the kernel to execute arbitrary code.
The simplest way to handle this would seem to be to add a new capability
and gate various
Secure boot adds certain policy requirements, including that root must not
be able to do anything that could cause the kernel to execute arbitrary code.
The simplest way to handle this would seem to be to add a new capability
and gate various functionality on that. We'll then strip it from the
Secure boot adds certain policy requirements, including that root must not
be able to do anything that could cause the kernel to execute arbitrary code.
The simplest way to handle this would seem to be to add a new capability
and gate various functionality on that. We'll then strip it from the
8 matches
Mail list logo