Hi Eric,
Your proposal seems reasonable to me.
Others — if you don't have time to read the full email, start reading
at "== Proposal==" for a summary of what is actually proposed. You
can go back and read the earlier part of the email for some discussion
of requirements and other options/context
On Mon, Mar 27, 2017 at 01:54:44PM -0400, Eric McCorkle wrote:
> Hello everyone,
>
> The following is a design proposal for signed kernel and kernel module
> loading, both at boot- and runtime (with the possibility open for signed
> executables and libraries if someone wanted to go that route). I
> 1) Be able to check for a correct cryptographic signature for any kernel
> or modules loaded at boot time for some platforms (EFI at a minimum).
I think it would be valid to have a boot from write protected device
(USB key) that does the initial kernel check and load and maybe stores
the keychai
On 03/29/2017 08:10, Peter Pentchev wrote:
>
> Erm, actually, the so-called "gnupg signature format", better known as
> "the OpenPGP signature format", is pretty well documented in RFC 4880.
> Note that this remark has no bearing on any of your other arguments, or
> on your work as a whole; I jus
On 03/29/2017 09:54, Michael Richards wrote:
>> 1) Be able to check for a correct cryptographic signature for any kernel
>> or modules loaded at boot time for some platforms (EFI at a minimum).
>
> I think it would be valid to have a boot from write protected device
> (USB key) that does the ini
On 03/27/2017 14:37, Shawn Webb wrote:
> The only other major thing to discuss is supporting public key chaining.
> Ideally, digital signature support should also support chaining multiple
> keys (similar to X.509 PKI). If the accepted solution supported cert
> chaining, then the solution would be
On Mon, Mar 27, 2017 at 01:54:44PM -0400, Eric McCorkle wrote:
> As background, the ELF file format has a number of different section
> types, only some of which comprise the program/library/module's runtime
> state. The ELF specification and tools provide some "standard" sections
> with defined m
On 03/29/2017 23:25, Konstantin Belousov wrote:
> First, you mix or do not understand a difference between section and segment.
> Second, this scheme allows to add loadable segments after signing.
> Third, most important, it has zero chances of working for amd64 modules.
That design has been aban
