Forum Debian Users Gang

Na razie mam klucze 2048.

I nie tylko mój bios jest do d, ale jakaś implementacja, sporo jest wątków z tym problemem na necie.

Co się githuba tyczy, znam ten adres.

Ale najpierw muszę spróbować shim-15.6 z Fedory.

Ostatnio edytowany przez Jacekalex (2020-06-13 16:21:01)

W zasadzie tak, ino że te klucze w MokList też nie są używalne w systemie UEFI, i np Debiana podpisanego Debian Boot CA nie mogłem odpalić do czasu, aż usunąłem podpis Debiana, i podpisalem go własnym kluczem.

Na razie zrezygnowałem z MokList na dobre.

Udalo mi się wreszcie użyć jednego certu do UEFI db.cert i w kernelu do podpisywania modułów.
Robiony wg twojego tutka klucz dk.key nie dzialal w kernelu, także zrobiłem nowy cert wg tego tutka:
https://www.kernel.org/doc/html/v4.15/admin-guide/module-signing.html
i ten działa zarówno w UEFI jak i w kernelu, tylko zmieniłem mu długość na 2048 (na kernel.org polecają 4096).

Wczytuje się do kernela grzecznie z obu źródeł:

02ec35b2 I------     1 perm 1f010000     0     0 asymmetri domek.cert: 66e6fda79eca0e6c3f9bd81b84fc7b766456a800: X509.rsa 6456a800 []
29a3667f I------     1 perm 1f030000     0     0 asymmetri domek.cert: 66e6fda79eca0e6c3f9bd81b84fc7b766456a800: X509.rsa 6456a800 []

Ostatnio edytowany przez Jacekalex (2020-06-14 02:26:28)

Morfik napisał(-a):

Którego tutka?

jacekalex napisał(-a):

Udalo mi się wreszcie użyć jednego certu do UEFI db.cert i w kernelu do podpisywania modułów.
Robiony wg twojego tutka klucz dk.key nie dzialal w kernelu, także zrobiłem nowy cert wg tego tutka:
https://www.kernel.org/doc/html/v4.15/admin-guide/module-signing.html
i ten działa zarówno w UEFI jak i w kernelu, tylko zmieniłem mu długość na 2048 (na kernel.org polecają 4096).

https://www.kernel.org/doc/html/v4.15/admin-guide/module-signing.html napisał(-a):

Under normal conditions, when CONFIG_MODULE_SIG_KEY is unchanged from its default, the kernel build will automatically generate a new keypair using openssl if one does not exist in the file:

certs/signing_key.pem

during the building of vmlinux (the public part of the key needs to be built into vmlinux) using parameters in the:

certs/x509.genkey

file (which is also generated if it does not already exist).

It is strongly recommended that you provide your own x509.genkey file.

Most notably, in the x509.genkey file, the req_distinguished_name section should be altered from the default:

[ req_distinguished_name ]
#O = Unspecified company
CN = Build time autogenerated kernel key
#emailAddress = unspecified.user@unspecified.company

The generated RSA key size can also be set with:

[ req ]
default_bits = 4096

It is also possible to manually generate the key private/public files using the x509.genkey key generation configuration file in the root node of the Linux kernel sources tree and the openssl command. The following is an example to generate the public/private key files:

openssl req -new -nodes -utf8 -sha256 -days 36500 -batch -x509 \
   -config x509.genkey -outform PEM -out kernel_key.pem \
   -keyout kernel_key.pem

The full pathname for the resulting kernel_key.pem file can then be specified in the CONFIG_MODULE_SIG_KEY option, and the certificate and key therein will be used instead of an autogenerated keypair.

Pozdro

Ostatnio edytowany przez Jacekalex (2020-06-14 23:07:02)

Klucz db.key wg twojego tutka ładnie działa w UEFI, ale nie działał u mnie w podpisywaniu modułów kernela poprzez /usr/src/linux/scripts/sign-file, dlatego zrobiłem klucz wg dokumentacji kernela,
i wsadziłem go do UEFI jako klucz db.

W ten sposób i jajo do SecureBoot i moduły kernela są podpisywane jednym kluczem,
Czyli osiagnałem w ten sposób zakładany cel, o który mi chodziło.

Ostatnio edytowany przez Jacekalex (2020-06-15 01:44:20)

db.pem dla kernela zrobiłem, ale i tak był problem.
Nie wnikałem, czy to wina Libressl czy sposobu generowania klucza, ale po prostu zrobiłem klucz wg przepisu na kernel.org.