05 Dec, 2012

1 commit

  • Don't use enum-type bitfields in the module signature info block as we can't be
    certain how the compiler will handle them. As I understand it, it is arch
    dependent, and it is possible for the compiler to rearrange them based on
    endianness and to insert a byte of padding to pad the three enums out to four
    bytes.

    Instead use u8 fields for these, which the compiler should emit in the right
    order without padding.

    Signed-off-by: David Howells
    Signed-off-by: Rusty Russell

    David Howells
     

22 Oct, 2012

1 commit

  • Fix the warning:

    kernel/module_signing.c:195:2: warning: format '%lu' expects type 'long unsigned int', but argument 3 has type 'size_t'

    by using the proper 'z' modifier for printing a size_t.

    Signed-off-by: Randy Dunlap
    Cc: David Howells
    Signed-off-by: Linus Torvalds

    Randy Dunlap
     

20 Oct, 2012

1 commit

  • Emit the magic string that indicates a module has a signature after the
    signature data instead of before it. This allows module_sig_check() to
    be made simpler and faster by the elimination of the search for the
    magic string. Instead we just need to do a single memcmp().

    This works because at the end of the signature data there is the
    fixed-length signature information block. This block then falls
    immediately prior to the magic number.

    From the contents of the information block, it is trivial to calculate
    the size of the signature data and thus the size of the actual module
    data.

    Signed-off-by: David Howells
    Signed-off-by: Linus Torvalds

    David Howells
     

10 Oct, 2012

2 commits

  • Check the signature on the module against the keys compiled into the kernel or
    available in a hardware key store.

    Currently, only RSA keys are supported - though that's easy enough to change,
    and the signature is expected to contain raw components (so not a PGP or
    PKCS#7 formatted blob).

    The signature blob is expected to consist of the following pieces in order:

    (1) The binary identifier for the key. This is expected to match the
    SubjectKeyIdentifier from an X.509 certificate. Only X.509 type
    identifiers are currently supported.

    (2) The signature data, consisting of a series of MPIs in which each is in
    the format of a 2-byte BE word sizes followed by the content data.

    (3) A 12 byte information block of the form:

    struct module_signature {
    enum pkey_algo algo : 8;
    enum pkey_hash_algo hash : 8;
    enum pkey_id_type id_type : 8;
    u8 __pad;
    __be32 id_length;
    __be32 sig_length;
    };

    The three enums are defined in crypto/public_key.h.

    'algo' contains the public-key algorithm identifier (0->DSA, 1->RSA).

    'hash' contains the digest algorithm identifier (0->MD4, 1->MD5, 2->SHA1,
    etc.).

    'id_type' contains the public-key identifier type (0->PGP, 1->X.509).

    '__pad' should be 0.

    'id_length' should contain in the binary identifier length in BE form.

    'sig_length' should contain in the signature data length in BE form.

    The lengths are in BE order rather than CPU order to make dealing with
    cross-compilation easier.

    Signed-off-by: David Howells
    Signed-off-by: Rusty Russell (minor Kconfig fix)

    David Howells
     
  • We do a very simple search for a particular string appended to the module
    (which is cache-hot and about to be SHA'd anyway). There's both a config
    option and a boot parameter which control whether we accept or fail with
    unsigned modules and modules that are signed with an unknown key.

    If module signing is enabled, the kernel will be tainted if a module is
    loaded that is unsigned or has a signature for which we don't have the
    key.

    (Useful feedback and tweaks by David Howells )

    Signed-off-by: Rusty Russell
    Signed-off-by: David Howells
    Signed-off-by: Rusty Russell

    Rusty Russell