# data[].attributes.body
PREMESSA

All’interno degli applicativi del TPT è stato sviluppato un sistema per il controllo di alcune funzionalità del TPT, chiamate capability. Ad esempio, una capability potrebbe essere la possibilità di adoperare un segnale GPS o la presenza di un sistema anti tamper.

Il controllo delle capability del TPT avviene utilizzando la configurazione del TPT e 2 file:

1. /tpt2000/config/PN.txt, che contiene il part number del TPT

2. /tpt2000/config/PNLIST.txt, che contiene una lista di tutti i part number possibili per TPT, raggruppati per righe.
Part number appartenenti alla stessa riga sono equivalenti dal punto di vista delle capability.

Se anche solo 1 di questi 2 file non è presente, le capability assegnate dal TPT dipenderanno solo dalla configurazione in uso e sarà possibile caricare qualsiasi configurazione sul TPT.

FORMATO FILE PNLIST.txt

Il file deve essere composto da righe nel formato

<PN_riferimento>,<PN_equivalente1>,<PN_equivalente2>,<PN_equivalente3><EOL>

I part number devono essere separati da virgole e senza spazi. Si assume che la lunghezza del part number sia sempre la stessa (9 cifre).

Ogni valore <PN_riferimento> deve essere concordato prima della compilazione del tpt_dist, dato che deve essere una stringa codificata all’interno del sorgente degli applicativi, gli altri valori <PN_equivalenteX> non devono essere concordati in precedenza e possono essere aggiunti anche successivamente.

Ai TPT con part number uguale a <PN_equivalenteX> verranno assegnate le stesse capability dei TPT con part number <PN_riferimento>.

Un esempio di PNLIST.txt potrebbe essere:

467017031

161195101

467017041

dove “467017031” è il part number di un CS2 ridotto, “161195101” è il part number di un CS2 e “467017041” è il part number di un LITE.

Ad esempio possiamo poi aggiungere “AAAAAAAAA” alla riga del part number del CS2:

467017031

161195101,AAAAAAAAA

467017041

In questo modo, se in un TPT il file PN.txt contiene il part number “AAAAAAAAA”, a esso verranno assegnate le capability di un CS2.

GESTIONE FILE PNLIST.txt

Il file PNLIST.txt deve essere presente sulla chiavetta di installazione del SO e potrà essere aggiornato in maniera indipendente dal software di SO e dagli applicativi.

# data[].attributes.body
-cerca la cartella contenente i simboli della tipologia di tastiera che ti interessa (in Ubuntu 22.04 la cartella è /usr/share/X11/xkb/symbols). Questa cartella è la cartella che contiene le informazioni che ci servono per creare una mappa (non binario) della tastiera che vogliamo

-in questa cartella trovare il file contenente i simboli che ti interessano (i nomi dei file sono abbreviazioni degli stati di riferimento, come "it" per "italia").

-digitare "ckbcomp "nome_simbolo_tastiera" -variant "variante" | loadkeys -ub > "path_binario_mappa". Le varianti possono essere lette nel file "nome_simbolo_tastiera" nella voce "xkb_symbols"

# data[].attributes.body
Il controllo sulla correttezza di una configurazione viene effettuato in parser_cfg.c

Configurazioni da scartare :

Per il LITE, il CS2 e il CS2_RID tutte quelle in cui viene usata la seconda linea del modbus. In particolare quando MBPERIPH=7, ovvero il periferico Modbus viene settato pari a EasySat.

Per il CS2 e il CS2_RID tutte le configurazioni in cui GPS=1 poichè nelle loro bitmap delle capabilities non è presente quella del GPS;

Per il CS2 e il CS2_RID tutte le configurazioni in cui KIND=LIT;

Per il CS2_RID tutte le configurazioni in cui KIND=STD.

Per il LITE e quando KIND=LIT tutte le configurazione dove o il numero dei TS > 12, o il numero dei TC > 4 o quando il numero dei TM > 0;

Configurazioni dove viene dichiarata una sezione diversa da quelle stabilite.

Configurazione in cui vengono impostati dei segnali sul secondo Modbus.

# data[].attributes.body
Le capabilities definite permettono di capire su che tipo di hardware si sta lavorando, ovvero se è un LITE, un CS2 o un CS2_RIDOTTO.

Per ogni tipo di hardware verrà generata una bitmap delle capabilities che li caratterizza.

Le bit map dipenderanno da due fattori:

dal port number, definito in /etc/config/PN.txt, che sarà diverso per ogni tipo di hardware e verrà letto con la funzione read_part_number();

dal KIND, definito in /etc/config/CFG.TXT, che verrà letto con la funzione Tpt_GetKind();

Tpt_GetCapability ritorna true solo se la capability presa in esame appartiene alla bitmap delle capabilities dell'hardware su cui stiamo lavorando.

# data[].attributes.body
Modificare procedura TPT2020CS: rigenerare il certificato e usare la stessa procedura [2]

Idea: usare nitrokey per generare certificato per firma pacchetti (esportare chiave pubblica per copia su immagine OS TPT)

Link utili:

[1]

https://padlet.com/redirect?url=https%3A%2F%2Fpagefault.blog%2F2019%2F04%2F22%2Fhow-to-sign-and-verify-using-openssl%2F

[2]

https://padlet.com/ebaldinotti/tpt2020cs-xdfoz6ndtj6w/wish/717673130

# data[].attributes.body
nel file /sys/kernel/debug/gpio leggere l'intervallo di numeri associato a ogni gpiochip, ogni numero si riferisce a un pin del gpio.

Inserire il numero del pin come valore di PPS_GPIO all'interno del sorgente del modulo gpio-poll, oppure inserirlo quando viene inserito il modulo col comando

insmod gpio-poll.ko gpio_number=<num>

# data[].attributes.body
1) Fai il clone del repository git tpt_usb_mac_programmer
-link ssh: git@gitlab.com:e.conte/tpt_usb_mac_programmer.git
-link https:
https://gitlab.com/e.conte/tpt_usb_mac_programmer.git
2) Formatta una chiavetta USB (dimensione minima 4GB) in formato fat32
3) Copia l'intero contenuto del repository tpt_usb_mac_programmer all'interno della chiavetta
4) Inserire la chiavetta usb e una tastiera nel tpt (usare hub USB)
5) Avviare il TPT e entrare nel BIOS
6) Andare nella scheda "Save & Exit" e premere invio sulla voce "Launch EFI Schell from filesystem device"
7) Attendere la fine dello script

NOTA: il binario necessario alla programmazione del MAC address è stato salvato sul NAS nella cartella del tpt2020lite sotto "risorse TPT"

# data[].attributes.body
/sys/class/rtc/rtc0/timestamp0 per tampering
/sys/bus/i2c/devices/1-0048/iio:device0/in_voltage0_raw per il voltaggio

# data[].attributes.body
https://docs.google.com/spreadsheets/d/1PQf0eKXiK98wzZ1Cv-ZVDPRfz67uZHqfjI-yi3AdCJU/edit?usp=sharing

# data[].attributes.body
1) Leggere che numero di bus e che numero di device hanno i cp210x con il comando "./cp210x-cfg -l".
Per ognuna delle voci uscite digitare il comando "./cp210x-cfg -d <numero_bus>.<numero_device>" e leggere il numero seriale di ciascun cp210x.
2) Cercare nella cartella "/sys/bus/usb/devices/" quale dispositivo corrisponde al cp210x del gps e diagnostica. Una volta trovato, leggere il suo numero seriale con il comando "cat /sys/bus/usb/devices/<device_trovato>/serial". Confrontare questo seriale con quelli visti prima per trovare il numero bus e il numero device corretti.
3) Riprogrammare il cp210x con il comando "./cp210x-cfg -d <numero_bus>.<numero_device> -M 0000".

ATTENZIONE: non programmare il cp2105 quando l'expansion board è collegata

# data[].attributes.body
https://wejn.org/2021/09/fixing-grub-verification-requested-nobody-cares/

PROCEDURA PER FAR FUNZIONARE GRUB CON SECURE BOOT:
1)digitare il comando "sed -i 's/SecureBoot/SecureB00t/' <binario-efi-grub>", ciò disabiliterà il controllo da parte di grub del kernel del nostro sistema operativo.
2)firmare il binario di grub con la nostra chiave con il comando "sbsign --key <chiave-privata> --cert <chiave-pubblica> --output <nome-output> <binario-efi-grub>".

È necessario rispettare l'ordine di questi 2 passaggi, se prima si firma e poi si applica il fix con sed la firma viene invalidata.

# data[].attributes.attachment_link.readable_text
Problem statement

Previously I described my secure boot with fully encrypted filesystem setup on Alpine Linux. Recently I had a chance to run that same script when installing another machine. To my surprise, grub greeted me with:
error: verification requested but nobody cares: (cryptouuid/$PARTITION_UUID)/grub/x86_64-efi/normal.mod
A quick search shows that I'm not alone in this predicament, and that this problem exists since grub 2.06 (but is absent in the 2.04).

In this post I'll describe my solution to this problem as well as several dead ends along the way.

Spoiler: sed -i 's/SecureBoot/SecureB00t/' grubx64.efi, but do consider the context!

Reminder: current setup

The current architecture of my secureboot + disk encryption (cribbed from the post linked above) is:

and the relevant portion of my grub setup is:

Script (click to expand)

cat - >/mnt/etc/default/grub <<- __EOF__ GRUB_DISTRIBUTOR="Alpine" GRUB_TIMEOUT=2 GRUB_DISABLE_SUBMENU=y GRUB_DISABLE_RECOVERY=true GRUB_PRELOAD_MODULES="luks cryptodisk part_gpt lvm" GRUB_ENABLE_CRYPTODISK=y GRUB_DEVICE=nvmetank/ROOT/alpine GRUB_DISABLE_LINUX_PARTUUID=true GRUB_DISABLE_LINUX_UUID=true __EOF__ sed -i 's/^modules=.*/modules=nvme,zfs/' /mnt/etc/update-extlinux.conf chroot /mnt grub-mkconfig -o /boot/grub/grub.cfg chroot /mnt grub-install --target =x86_64-efi --efi-directory =/efi # The grub install partially fails (the call to efibootmgr does) because of raid. # Because grub tries to give two devices to efibootmgr (who doesn't like that). # # It's fine, tho, we can use the fallback /EFI/boot/bootx64.efi path within ESP. mkdir /mnt/efi/EFI/boot mv /mnt/efi/EFI/alpine/grubx64.efi /mnt/efi/EFI/boot/bootx64.efi rmdir /mnt/efi/EFI/alpine # Oh, and grub, f-off with grubenv, will ya? It's on RAID anyway. rm /mnt/boot/grub/grubenv # -------------------------------------------------------- # Time to setup the glorious Secure boot mkdir -m 0700 /mnt/boot/secureboot # Generate the cert openssl req -new -x509 -newkey rsa:2048 -keyout /mnt/boot/secureboot/sb.key \ -out /mnt/boot/secureboot/sb.crt -nodes -days 36500 -subj "/CN=Wejn SB CA/" openssl x509 -in /mnt/boot/secureboot/sb.crt -out /mnt/boot/secureboot/sb.cer -outform DER # Sign grub. This is, btw, the command you'll be re-running if you update grub # binary sometime later (along with the "mv" a few lines above, I guess). sbsign --key /mnt/boot/secureboot/sb.key --cert /mnt/boot/secureboot/sb.crt \ /mnt/efi/EFI/boot/bootx64.efi mv /mnt/efi/EFI/boot/bootx64.efi.signed /mnt/efi/EFI/boot/bootx64.efi # Copy the "sb.cer" so it can be added to bios. I have it as all of: PK, KEK, db. cp /mnt/boot/secureboot/sb.cer /mnt/efi/sb.cer

I briefly checked the 'Net and several folks mentioned that the error is due to "shim lock" or grub not having all the modules preloaded.

That's fair; let's dive in.

Dead end #1: I'll just inline all modules

At first I thought - fine, let's embed all the modules, that will teach it:

Which absolutely doesn't work. Don't even bother.

This, btw, shows my level of expertise when it comes to grub2.

Dead end #2: I'll inline the modules properly

Okay, so I'll inline the modules properly and life will be good:

So modules are pre-loaded. The final list took a couple of tries, but what's a few tens of reboots between friends?

Also had to --disable-shim-lock to disable the next error about missing shim protocol.

And now it bombs again, this time it fails to load kernel and ramdisk, because they aren't verified:

OK, you're getting annoying, grub.

Dead end #3: Fine! I'll sign everything with PGP!

Okay, so I read the Using digital signatures section of the Grub manual (and a fair bit more of the documentation, actually).

Sounds like an overkill (since without decrypting the boot partition you won't be booting much of anything), but what the hell:

Surely this will work...

Nope.

Dies with error: verification requested but nobody cares again. And I'm getting pissed off.

Maybe I have the keyfile wrong?

Nope, because Secure Boot with GRUB 2 and signed Linux images and initrds uses the same export method.

Maybe I'm missing the set check_signatures=enforce in grub.cfg? Nope, still fails.

Maybe I'm missing verify.mod? But there isn't a module of that name in Alpine.

And I've had enough.

Solution

Having exhausted all reasonable attempts at finding a standard solution (that would play nicely with grub's silliness), it's time to bring the big guns.

During my searches regarding the error I found a post detailing a patch someone made to the shim_lock that gave me an idea.

I fetched grub's source and found the following pearl:

But oh baby! Why didn't you say that earlier?!

So all of this grub silliness is controlled by a single EFI variable (whatever that is exactly) that BIOS supplies when booting?

Well, that's an easy fix, then:

In other words - since BIOS authenticates my grub binary, and grub binary only loads the rest when it can successfully decrypt the /boot partition, I don't need this signing silliness. In fact, I don't need grub to get involved at all.

By binary editing the generated efi binary and replacing SecureBoot with SecureB00t, I effectively disable any "secure boot" half-cooked and severely over-engineered functionality in grub.

Profit!

Closing words

I have a slightly bad feeling posting this. Because blindly applying thix "fix" without due consideration of the surrounding context might make other people's boot process insecure.

But mindlessly applying commands found on the 'Net was always fraught with risk, yes?

And anyway, I still think that the secure boot implementation in grub is both needlessly over-engineered and half-cooked.

And if it saves someone from spending 3+ hours debugging their otherwise perfectly valid setup... just because someone decided to unilaterally break their bootloader in a minor release, then I think it's more than fair.

# data[].attributes.attachment_link.title
Fixing grub 2.06 "error: verification requested but nobody cares"

# data[].attributes.attachment_link.description
Previously I described my secure boot with fully encrypted filesystem setup on Alpine Linux. Recently I had a chance to run that same script when installing another machine. To my surprise, grub greeted me with: error: verification requested but nobody cares: (cryptouuid/$PARTITION_UUID)/grub/x86_64-efi/normal.mod A quick search shows that I'm not alone in this predicament, and that this problem exists since grub 2.06 (but is absent in the 2.04).

# data[].attributes.body
1)copiare sul target i moduli "gpio-pca953x.ko" e "regmap-i2c.ko" dalla cartella "/opt/tpt_driver/ko" del server
2) digitare il comando "echo pca9555 <indirizzo_hex_i2c_pca9555>  > /sys/bus/i2c/devices/i2c-1/new_device" per ogni dispositivo pca9555, dove <indirizzo_hex_i2c_pca9555> è l'indirizzo in esadecimale del dispositivo che si vuole aggiungere. Questo indirizzo si può ricavare confrontando il datasheet del pca9555 nella sezione 8.5.2.1 con gli schematici (per ora gli indirizzi sono 0x21 e 0x25)
3)caricare il modulo "regmap-i2c.ko"
4)caricare il modulo "gpio-pca953x.ko".
Dopo questi passaggi devono comparire due dispositivi "gpiochip0" e "gpiochip1" sotto la cartella "/dev/"

# data[].attributes.body
repo git driver tpt ssh: git@gitlab.com:e.conte/tpt_driver.git
repo git driver tpt https: https://gitlab.com/e.conte/tpt_driver.git

PROCEDURA
passaggi da fare per generare un pps a partire dal segnale gps su tpt2020lite. ATTENZIONE: prima è necessario configurare i cp2105 (vedere nota su padlet).

1) compilare il sorgente cp210x.c presente nella cartella git "tpt_driver" nella cartella "cp210" usando il Makefile presente (nel quale va inserito il path del kernel usato dal tpt2020lite, presente sul server nella cartella /opt/linux/").
2) caricare il modulo appena compilato sul tpt2020lite
3) collegare il cavo dell'antenna gps al tpt
4) lanciare "gpsd -n <tty_gps_path>", dove <tty_gps_path> è il percorso della tty generata dal driver cp210x associata al gps (nel nostro caso ttyUSB4)

Dopo il procedimento viene generata la sorgente del pps nella cartella "/dev/". Si può verificare anche tramite gpsmon.
~

# data[].attributes.body
1)copiare sul target il modulo "pcf2131.ko" dalla cartella "/opt/tpt_driver/ko" del server
2)digitare il comando "echo pcf2131 0x53 > /sys/bus/i2c/devices/i2c-1/new_device"
3)caricare il modulo "pcf2131.ko"
Dopo questi passaggi deve comparire un dispositivo "rtc0" sotto la cartella "/dev/"

# data[].attributes.body
PROCEDURA

1)aprire /etc/ntp.conf con un editor a tua scelta

2)aggiungere le righe

" server 127.127.20.5 mode 17 minpoll 4 maxpoll 5 prefer true

fudge 127.127.20.5 time1 0.19 time2 0.6 refid GPS

server 127.127.22.0 minpoll 4 maxpoll 5 prefer true

fudge 127.127.22.0 refid PPS "

come in figura.

Per maggiori informazioni sui driver NTP usati:

https://www.ntp.org/documentation/drivers/driver20/

https://www.ntp.org/documentation/drivers/driver22/

Per maggiori informazioni sulle opzioni settate:

https://docs.ntpsec.org/latest/ntp_conf.html

Per controllare che tutto funzioni è possibile lanciare ntpd in modalità debug col comando "ntpd -d" oppure, mentre ntpd sta girando, si può usare il comando "ntpq -p"