Esquivándole el bulto al problema principal, que es implementar el ataque, sigo introduciendo cambios y mejorías, en este caso al Makefile.
Relacionado al Makefile, ya había puesto:
BOARD ?= edufpga
PROGRAM ?= hello
Lo primero debido a que desde ciaa/icicle para acá, es la placa que vamos a usar, no quiero estar poniendo BOARD=edufpga en cada llamada a make. Lo segundo es que el foco ha pasado de elegir el BOARD a elegir el PROGRAM.
Tambien había modificado la regla para defines.sv para que tome la configuración de puertos y dispositivos de la carpeta del programa. Esto implica que al hacer un nuevo programa, convienen hacer un make clean para que se reescriba con la nueva configuración.
Optimización del programa
Una mejoría está relacionada a la optimización del código del programa. Por default grahamedgecombe/icicle lo puso en -Os, que es razonable, hacer el programa lo más chico posible, menos RAM, menos ocupación de la FPGA. Pero para un inexperto como yo en assembly en general y de risc-v en particular, se me hace bastante complicado analizar el código para implementar el ataque, así que ahora existe la opción:
OPTLEVEL ?= -Os
si en la invocación agregás
OPTLEVEL=
como en
make PROGRAM=access_control OPTLEVEL=""
no optimiza.
Uso de azar en PNR
Apenas complicado fué el asunto del SEED. ¿Qué es el SEED? Pues que para el place and route funcione bien, el algoritmo utiliza pseudoazar.
¿Qué es place and route? Es el proceso de ubicar y conectar los componentes en un circuito electrónico en este caso en la FPGA.
¿Qué es pseudoazar? Bueno, primero veamos que es azar. Azar es... tirar los dados. El problema con el azar es que no podés repetirlo y si usás azar para algo, si tenés una falla y no lo podés repetir, se complica diagnosticar la cause. Pero necesitás el azar, ¿en qué quedamos?
El pseudoazar viene a ser tirar los dados un montón de veces y guardar lo que te salió en una lista. Luego, cuando lo necesitás tirás una sola vez los dados para elegir donde empezar en esa lista. Entonces tenés azar y repetición a la vez si necesitás, eligiendo la posición en la lista. Es un azar apto para estas cosas, pero no ante un adversario, pues no bien reusás la lista o comparando ejecuciones, se puede obtener la lista.
La gente que realmente sabe criptografía sabrá ser generosa con mi explicación.
Como el archivo generado depende entonces del pseudoazar, si necesito que dado el mismo diseño obtener el mismo placement and routing, necesito el control de SEED, que en nextprn-ice40 se determina con el parámetro --seed.
Me interesa que genere siempre lo mismo debido a que quizás para el ataque pueda, no creo, hacer la modificación no sobre el código HDL sino en una etapa posterior, veremos.
En el Makefile primero hay de definirlo con vacío como default:
SEED ?=
y luego en arch/ice40.mk, si SEED está vacío, sigue vacío, pero si hay algo, agregarle la key --speed.
ifeq ($(SEED),)
SEEDVAL =
else
SEEDVAL = --seed $(SEED)
endif
SEEDVAL luego es reemplazado en la línea:
nextpnr-ice40 $(QUIET) --$(SPEED)$(DEVICE) --package $(PACKAGE) $(SEEDVAL) --json $< --pcf $(PCF) --freq $(FREQ_PLL) --asc $@
¿Por qué no hice la misma lógica con OPTLEVEL? Buena pregunta... debe ser por que es fácil escribir "" y no "--seed 3".
Dependencias
 | |
| icicle flow high level |
Para comenzar, mover todo objeto temporario o construido a una carpeta, BUILD es un buen lugar, luego, mover los .ys a arch.
De tanto revisar como le fuí tomando la mano y generé un nuevo diagrama:
 |
| ICE40 flow low level |
El problema restante que me queda es el tiempo:
- yosys: 1:10
- nextpnr-ice40: 1:45
- iceprog: 2:00
Tengo que armar reglas de Makefile tal que pueda hacer tener estas cuatro:
- software: genera progmem.hex.
- hardware: genera top_syn.asc.
- system: genera top.bin.
- all: que haga todo sin tanta sutileza, lo que está ahora.
Será otro día...
- H4CK3D 2021: configuración básica
- H4CK3D 2021: leyendo los botones de la placa
- H4CK3D 2021: un desvío necesario
- H4CK3D 2021: un desvío innecesario
- H4CK3D 2021: sigue el desvío, para bien
- H4CK3D 2021: cambios al Makefile
- H4CK3D 2021: mejor resolución de dependencias en Makefile
- H4CK3D 2021: el escenario y el programa víctima
- H4CK3D 2021: el ataque concreto
- the missing pieces
- La charla con la demo
- El código fuente del SOC mejorado
- El código fuente del ataque
No hay comentarios:
Publicar un comentario