FSP switches SAI

Abierto
  • ¿Algo no está bien?
#24 3 comentarios 5 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
20/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Estancado
Stack tecnológico
c
Área
embedded-iot, security

Línea de trabajo

Comienza localizando dónde FSP cambia SAI a POSTBOOT_SAI y compara ese comportamiento con las tablas de registros de EDS; no se especifica ningún archivo fuente ni ninguna prueba concretos. Se consideraría terminado cuando se haya acordado el alcance para cambiar o documentar el cambio de SAI y se hayan validado sus implicaciones para el acceso del bootloader y la seguridad.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

FSP switches to POSTBOOT_SAI, there are several issues with that. TL;DR while it probably tries to achieve the opposite, it undermines firmware quality and security.

  • In some bootloaders FSP may run long before EOP, this means most of the bootloader runs with POSTBOOT_SAI.
  • In the EDS, implications of the SAI switch are not documented. Virtually for every register, it is unknown if it is still accessible after the SAI switch.
  • The SAI switch seems to force the bootloader to do some things in SMM. AFAIK, the use of SMM as a more privileged execution mode is generally discouraged, even internally at Intel. This means FSP forces bootloader development to go backwards.
  • Generally, security may be undermined if FSP locks something to early, i.e. in a state that doesn't play well with the security concept of the bootloader.

Especially the lack of documentation leads to many bugs in firmware. Even Intel developers working on bootloaders such as coreboot don't seem to know the implications of the SAI switch or lack the resources to re-evaluate all bootloader code wrt. the SAI switch. I fear there is currently a race to the bottom of firmware quality going on: the need to fix bugs eats too many resources which leads to more bugs for future products, eating even more resources. Plus, these resources are limited because of the lack of public documentation.

Two possible solutions come to mind:

  1. Do the SAI switch in the very last phase of FSP (or maybe even add an additional phase to lock things down?) and comprehensively document all the implications of the switch. For instance, in all the register tables, there could be column that mentions the applicable SAIs.
  2. Make the SAI switch optional in FSP and document how the boot loader can take care of it. This would not only prevent all SAI-switch related bugs but also leave the security concept in a single place, the bootloader. That the configuration of security mechanisms and their locking are currently split between bootloader and FSP makes it very hard to configure an Intel platform reasonably secure (unless you rely on additional security chips in your platform, which is not always affordable).

I think 1. is only feasible in the long run. But maybe it's not too late to set up 2. for all the FSPs that do the SAI switch yet?

Lenguaje dominante
C
Estrellas
366
Forks
143
Sin PR fusionados en 30 d

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de intel/FSP

Todos los issues de intel/FSP

Issues similares

Más issues de C

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.