From: David Howells <dhowells@redhat.com>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: dhowells@redhat.com, torvalds@linux-foundation.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] MODSIGN: Move the magic string to the end of a module and eliminate the search
Date: Mon, 22 Oct 2012 14:42:06 +0100 [thread overview]
Message-ID: <17155.1350913326@warthog.procyon.org.uk> (raw)
In-Reply-To: <874nlnjowo.fsf@rustcorp.com.au>
Rusty Russell <rusty@rustcorp.com.au> wrote:
> Meh, I really wanted to separate the module signature locating (my
> problem) from the decoding and checking (your problem).
You could split mod_verify_sig() at the:
/* For the moment, only support RSA and X.509 identifiers */
comment. At that point we have verified the size fields of the
module_signature struct and we have determined mod, modlen and sig.
Assuming a detached signature is going to look the same as an attached
signature, just without the magic number[1], then you can duplicate the first
part of mod_verify_sig() with the size checks.
[1] The signature may need to be kept small to make sure it will fit within an
xattr, just in case the host fs has limits.
> If we're going to require such a header, we can simplify further (untested!).
Do we want to require that a detached signature be exactly the same as an
appended signature, structure, magic string and all?
I'm also slightly against copying the magic string to the stack if we can avoid
it as the compiler can't recover the space before calling mod_verify_sig().
Besides, there's no particular need to copy the magic string.
> BTW, I'm not convinced your use of bitfields here is portable; it may be
> portable enough for Linux though.
I consulted a gcc engineer and he suggested that it's arch dependent, so I
should probably use u8. Since the enums are basically int-sized types, the
compiler might reorder them depending on endianness and might insert a byte of
padding.
It's just that I prefer the enums for documentary sake.
David
next prev parent reply other threads:[~2012-10-22 13:42 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-20 0:19 David Howells
2012-10-22 1:06 ` Rusty Russell
2012-10-22 13:42 ` David Howells [this message]
2012-10-24 1:13 ` Rusty Russell
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=17155.1350913326@warthog.procyon.org.uk \
--to=dhowells@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rusty@rustcorp.com.au \
--cc=torvalds@linux-foundation.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome