Alan Cox <a...@lxorguk.ukuu.org.uk> wrote:

> Why do this in the kernel.That appears to be completely insane.

A number of reasons:

 (1) The UEFI signature/key database may contain ASN.1 X.509 certificates and
     we may need to use those very early in the boot process, during initrd.

 (2) Even if userspace is available, offloading the key parsing to userspace
     means we have to have some way to trust what we get back.

 (3) Giving the kernel ASN.1 X.509 certs allows the kernel to verify the
     signature on that cert against a key it gets from the UEFI db.  For that,
     you need the raw cert.

> Can you prove it runs in a short bounded time for all inputs,

Possibly.  I'll have to think about that.  It may be relatively
straightforward.

 (1) The ASN.1 decoder is limited (currently) to a maximum of 64k of data to
     parse.

 (2) The decoder never goes backward through the data.

 (3) The decoder has a strictly limited recursion/nesting stack.

The decoder uses a state machine of a sort produced by the compiler.

 (1) Most nodes in this only have one transition.

 (2) Simple optional nodes are simply marked skippable.

 (3) There are some nodes that are like subroutine calls (for multiple-use
     constructed types), but these must return to the point directly after the
     call.

 (4) There are some nodes that have two transitions.  These are used for
     optional constructed type values (particularly multiple-use ones).
     Basically, they are jump-to-subroutine or skip.  The return must go back
     to the next node.

Writing a perl script to check the sanity of the compiler output should be easy
enough, though it would have to assume that the driver is sane.

> has it been fuzz tested extensively ?

Fuzz testing from a script is very easy, eg:

        #!/bin/sh
        cd /tmp
        sync
        declare -i n i j k
        while true
        do
            n=$RANDOM
            j=$RANDOM
            j=j%10
            k=0
            echo $n $j
            dd if=/dev/urandom of=/tmp/data bs=$n count=1
            for ((i=1; i<n; i=i+k))
            do
                dd if=/tmp/data bs=$i count=1 2>/dev/null |
                keyctl padd asymmetric foo @s 2>/dev/null
                k=k+1
                if [ $k -eq 10 ]
                    then
                    echo -n .
                    k=0
                fi
            done
            echo
        done

Though I haven't done a great deal of such testing as I want to be able to use
my test machine for other stuff too.  I can, however, run multiple fuzzers 
simultaneously.

I have also passed a number of bits of X.509 and PKCS#7 through it, and also
some valid ASN.1 that isn't what the decoder is expecting.

        #!/bin/sh

        file=/tmp/x509cert
        if [ "$1" != "" ]
        then
            file=$1
        fi

        cd /tmp
        sync

        while true
        do
            openssl req -new -x509 -outform PEM -keyout $file.pem -nodes -subj 
"/CN=GB/O=Red Hat/OU=Magrathea/CN=Slartibartfast" -out $file.x509 || exit $?

            openssl x509 -in $file.x509 -inform PEM -outform DER 
>$file.x509.asn1 || exit $?
            keyctl padd asymmetric bar @s <$file.x509.asn1 || exit $?

            n=$RANDOM
            if [ $n -lt 10 ]; then n=10; fi
            dd if=/dev/urandom of=$file.stuff bs=$n count=1

            openssl smime -sign -inkey $file.pem -signer $file.x509 -keyform 
PEM \
                -in $file.stuff -out $file.pkcs7 -binary -outform DER || exit $?

            keyctl padd asymmetric baz @s <$file.pkcs7
        done

Unfortunately, the above is somewhat limited in what it can produce.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to