¿Cómo ejecutar un programa sin un sistema operativo?

239

¿Cómo ejecuta un programa por sí solo sin un sistema operativo en ejecución? ¿Puede crear programas de ensamblaje que la computadora pueda cargar y ejecutar al inicio, por ejemplo, iniciar la computadora desde una unidad flash y ejecutar el programa que está en la CPU?

usuario2320609
fuente
44
¿Sobre qué arquitectura? x86? ¿BRAZO?
Kissiel
1
Estaba hablando en general, pero muy probablemente x86 o x64
user2320609
2
sí, así es exactamente como arrancan los procesadores. no tiene que ser ensamblado, C a menudo se usa con un poco de asm para un bootstrap y quizás algún otro soporte.
old_timer
24
Piénselo: si no hubiera tal capacidad, ¿cómo se iniciaría y ejecutaría el sistema operativo? :)
Seva Alekseyev

Respuestas:

153

¿Cómo ejecuta un programa por sí solo sin un sistema operativo en ejecución?

Coloca su código binario en un lugar donde el procesador busca después de reiniciar (por ejemplo, la dirección 0 en ARM).

¿Puede crear programas de ensamblaje que la computadora pueda cargar y ejecutar al inicio (por ejemplo, iniciar la computadora desde una unidad flash y ejecuta el programa que está en la unidad)?

Respuesta general a la pregunta: se puede hacer. A menudo se le conoce como "programación básica". Para leer desde una unidad flash, desea saber qué es USB y desea tener algún controlador para trabajar con este USB. El programa en esta unidad también tendría que estar en algún formato particular, en algún sistema de archivos particular ... Esto es algo que suelen hacer los cargadores de arranque, pero su programa podría incluir su propio cargador de arranque para que sea autónomo, si el firmware solo Cargue un pequeño bloque de código.

Muchas placas ARM le permiten hacer algunas de esas cosas. Algunos tienen cargadores de arranque para ayudarlo con la configuración básica.

Aquí puede encontrar un gran tutorial sobre cómo hacer un sistema operativo básico en una Raspberry Pi.

Editar: Este artículo, y todo el wiki.osdev.org responderá la mayoría de sus preguntas http://wiki.osdev.org/Introduction

Además, si no desea experimentar directamente en hardware, puede ejecutarlo como una máquina virtual utilizando hipervisores como qemu. Vea cómo ejecutar "hello world" directamente en hardware ARM virtualizado aquí .

Kissiel
fuente
723

Ejemplos ejecutables

Vamos a crear y ejecutar algunos minúsculos programas hello world que se ejecutan sin un sistema operativo en:

También los probaremos en el emulador QEMU tanto como sea posible, ya que es más seguro y más conveniente para el desarrollo. Las pruebas de QEMU se realizaron en un host Ubuntu 18.04 con la QEMU 2.11.1 preempaquetada.

El código de todos los ejemplos x86 a continuación y más está presente en este repositorio de GitHub .

Cómo ejecutar los ejemplos en hardware real x86

Recuerde que ejecutar ejemplos en hardware real puede ser peligroso, por ejemplo, podría borrar su disco o bloquear el hardware por error: ¡solo haga esto en máquinas viejas que no contienen datos críticos! O incluso mejor, use paneles de control semi desechables baratos como el Raspberry Pi, vea el ejemplo ARM a continuación.

Para una laptop x86 típica, debe hacer algo como:

  1. Grabe la imagen en una memoria USB (¡destruirá sus datos!):

    sudo dd if=main.img of=/dev/sdX
    
  2. conecte el USB a una computadora

  3. encenderlo

  4. dile que arranque desde el USB.

    Esto significa hacer que el firmware seleccione USB antes que el disco duro.

    Si ese no es el comportamiento predeterminado de su máquina, siga presionando Enter, F12, ESC u otras teclas extrañas después del encendido hasta que obtenga un menú de inicio donde puede seleccionar iniciar desde el USB.

    A menudo es posible configurar el orden de búsqueda en esos menús.

Por ejemplo, en mi T430 veo lo siguiente.

Después de encender, es cuando tengo que presionar Enter para ingresar al menú de arranque:

ingrese la descripción de la imagen aquí

Entonces, aquí tengo que presionar F12 para seleccionar el USB como dispositivo de arranque:

ingrese la descripción de la imagen aquí

A partir de ahí, puedo seleccionar el USB como dispositivo de arranque de esta manera:

ingrese la descripción de la imagen aquí

Alternativamente, para cambiar el orden de arranque y elegir el USB para tener mayor prioridad para que no tenga que seleccionarlo manualmente cada vez, presionaría F1 en la pantalla "Menú de interrupción de inicio" y luego navegaría a:

ingrese la descripción de la imagen aquí

Sector de arranque

En x86, lo más simple y de nivel más bajo que puede hacer es crear un Sector de arranque maestro (MBR) , que es un tipo de sector de arranque , y luego instalarlo en un disco.

Aquí creamos uno con una sola printfllamada:

printf '\364%509s\125\252' > main.img
sudo apt-get install qemu-system-x86
qemu-system-x86_64 -hda main.img

Salir:

ingrese la descripción de la imagen aquí

Tenga en cuenta que incluso sin hacer nada, algunos caracteres ya están impresos en la pantalla. Los imprime el firmware y sirven para identificar el sistema.

Y en el T430 solo tenemos una pantalla en blanco con un cursor parpadeante:

ingrese la descripción de la imagen aquí

main.img contiene lo siguiente:

  • \364en octal == 0xf4en hexadecimal: la codificación de una hltinstrucción, que le dice a la CPU que deje de funcionar.

    Por lo tanto, nuestro programa no hará nada: solo iniciar y detener.

    Usamos octal porque \xPOSIX no especifica los números hexadecimales.

    Podríamos obtener esta codificación fácilmente con:

    echo hlt > a.S
    as -o a.o a.S
    objdump -S a.o
    

    que salidas:

    a.o:     file format elf64-x86-64
    
    
    Disassembly of section .text:
    
    0000000000000000 <.text>:
       0:   f4                      hlt
    

    pero también está documentado en el manual de Intel, por supuesto.

  • %509sProduce 509 espacios. Necesario para completar el archivo hasta el byte 510.

  • \125\252en octal == 0x55seguido de 0xaa.

    Estos son 2 bytes mágicos requeridos que deben ser los bytes 511 y 512.

    El BIOS revisa todos nuestros discos en busca de dispositivos de arranque, y solo considera aquellos de arranque que tienen esos dos bytes mágicos.

    Si no está presente, el hardware no lo tratará como un disco de arranque.

Si no eres un printfmaestro, puedes confirmar el contenido de main.imgcon:

hd main.img

que muestra lo esperado:

00000000  f4 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20  |.               |
00000010  20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20  |                |
*
000001f0  20 20 20 20 20 20 20 20  20 20 20 20 20 20 55 aa  |              U.|
00000200

donde 20hay un espacio en ASCII.

El firmware del BIOS lee esos 512 bytes del disco, los guarda en la memoria y configura la PC en el primer byte para comenzar a ejecutarlos.

Hola sector de arranque mundial

Ahora que hemos creado un programa mínimo, pasemos a un mundo hola.

La pregunta obvia es: ¿cómo hacer IO? Algunas opciones:

  • pedirle al firmware, por ejemplo, BIOS o UEFI, que lo haga por nosotros

  • VGA: región de memoria especial que se imprime en la pantalla si se escribe en ella. Se puede usar en modo protegido.

  • escriba un controlador y hable directamente al hardware de la pantalla. Esta es la forma "adecuada" de hacerlo: más potente, pero más complejo.

  • puerto serie . Este es un protocolo estandarizado muy simple que envía y recibe caracteres desde un terminal host.

    En los escritorios, se ve así:

    ingrese la descripción de la imagen aquí

    Fuente .

    Desafortunadamente, no está expuesto en la mayoría de las computadoras portátiles modernas, pero es la forma más común de obtener placas de desarrollo, consulte los ejemplos de ARM a continuación.

    Esto es realmente una pena, ya que tales interfaces son realmente útiles para depurar el kernel de Linux, por ejemplo .

  • utilizar funciones de depuración de chips. ARM llama a ellos semihosting, por ejemplo. En hardware real, requiere soporte adicional de hardware y software, pero en emuladores puede ser una opción conveniente y gratuita. Ejemplo .

Aquí haremos un ejemplo de BIOS, ya que es más simple en x86. Pero tenga en cuenta que no es el método más robusto.

red eléctrica

.code16
    mov $msg, %si
    mov $0x0e, %ah
loop:
    lodsb
    or %al, %al
    jz halt
    int $0x10
    jmp loop
halt:
    hlt
msg:
    .asciz "hello world"

GitHub aguas arriba .

link.ld

SECTIONS
{
    /* The BIOS loads the code from the disk to this location.
     * We must tell that to the linker so that it can properly
     * calculate the addresses of symbols we might jump to.
     */
    . = 0x7c00;
    .text :
    {
        __start = .;
        *(.text)
        /* Place the magic boot bytes at the end of the first 512 sector. */
        . = 0x1FE;
        SHORT(0xAA55)
    }
}

Ensamblar y vincular con:

as -g -o main.o main.S
ld --oformat binary -o main.img -T link.ld main.o
qemu-system-x86_64 -hda main.img

Salir:

ingrese la descripción de la imagen aquí

Y en el T430:

ingrese la descripción de la imagen aquí

Probado en: Lenovo Thinkpad T430, UEFI BIOS 1.16. Disco generado en un host Ubuntu 18.04.

Además de las instrucciones de montaje estándar del usuario, tenemos:

  • .code16: le dice a GAS que muestre código de 16 bits

  • cli: deshabilita las interrupciones de software. Esos podrían hacer que el procesador vuelva a funcionar después dehlt

  • int $0x10: hace una llamada de BIOS. Esto es lo que imprime los personajes uno por uno.

Los indicadores de enlace importantes son:

  • --oformat binary: genera un código de ensamblaje binario sin formato, no lo envuelva dentro de un archivo ELF, como es el caso de los archivos ejecutables del usuario habitual.

Para comprender mejor la parte del script del enlazador, familiarícese con el paso de reubicación del enlace: ¿Qué hacen los enlazadores?

Programas de metal desnudo Cooler x86

Aquí hay algunas configuraciones de metal desnudo más complejas que he logrado:

Use C en lugar de ensamblar

Resumen: use el arranque múltiple de GRUB, que resolverá muchos problemas molestos en los que nunca pensó. Vea la sección a continuación.

La principal dificultad en x86 es que el BIOS solo carga 512 bytes del disco a la memoria, ¡y es probable que explote esos 512 bytes cuando usa C!

Para resolver eso, podemos usar un gestor de arranque de dos etapas . Esto hace más llamadas de BIOS, que cargan más bytes del disco a la memoria. Aquí hay un ejemplo mínimo de ensamblaje de la etapa 2 desde cero usando las llamadas int 0x13 BIOS :

Alternativamente:

  • si solo necesita que funcione en QEMU pero no en hardware real, use la -kernelopción, que carga un archivo ELF completo en la memoria. Aquí hay un ejemplo ARM que he creado con ese método .
  • para el Raspberry Pi, el firmware predeterminado se encarga de la carga de imágenes para nosotros desde un archivo ELF llamado kernel7.img, al igual que QEMU -kernel.

Solo con fines educativos, aquí hay un ejemplo mínimo de C en una etapa :

C Principal

void main(void) {
    int i;
    char s[] = {'h', 'e', 'l', 'l', 'o', ' ', 'w', 'o', 'r', 'l', 'd'};
    for (i = 0; i < sizeof(s); ++i) {
        __asm__ (
            "int $0x10" : : "a" ((0x0e << 8) | s[i])
        );
    }
    while (1) {
        __asm__ ("hlt");
    };
}

entrada S

.code16
.text
.global mystart
mystart:
    ljmp $0, $.setcs
.setcs:
    xor %ax, %ax
    mov %ax, %ds
    mov %ax, %es
    mov %ax, %ss
    mov $__stack_top, %esp
    cld
    call main

linker.ld

ENTRY(mystart)
SECTIONS
{
  . = 0x7c00;
  .text : {
    entry.o(.text)
    *(.text)
    *(.data)
    *(.rodata)
    __bss_start = .;
    /* COMMON vs BSS: /programming/16835716/bss-vs-common-what-goes-where */
    *(.bss)
    *(COMMON)
    __bss_end = .;
  }
  /* /programming/53584666/why-does-gnu-ld-include-a-section-that-does-not-appear-in-the-linker-script */
  .sig : AT(ADDR(.text) + 512 - 2)
  {
      SHORT(0xaa55);
  }
  /DISCARD/ : {
    *(.eh_frame)
  }
  __stack_bottom = .;
  . = . + 0x1000;
  __stack_top = .;
}

correr

set -eux
as -ggdb3 --32 -o entry.o entry.S
gcc -c -ggdb3 -m16 -ffreestanding -fno-PIE -nostartfiles -nostdlib -o main.o -std=c99 main.c
ld -m elf_i386 -o main.elf -T linker.ld entry.o main.o
objcopy -O binary main.elf main.img
qemu-system-x86_64 -drive file=main.img,format=raw

Biblioteca estándar C

Sin embargo, las cosas se vuelven más divertidas si también desea utilizar la biblioteca estándar de C, ya que no tenemos el kernel de Linux, que implementa gran parte de la funcionalidad de la biblioteca estándar de C a través de POSIX .

Algunas posibilidades, sin recurrir a un sistema operativo completo como Linux, incluyen:

  • Escribe lo tuyo. Es solo un montón de encabezados y archivos C al final, ¿verdad? ¿¿Correcto??

  • Newlib

    Ejemplo detallado en: /electronics/223929/c-standard-libraries-on-bare-metal/223931

    Implementos NEWLIB todas las cosas aburridas no OS específicas para que, por ejemplo memcmp, memcpy, etc.

    Luego, proporciona algunos apéndices para que pueda implementar las llamadas al sistema que necesita.

    Por ejemplo, podemos implementar exit()en ARM a través de semihosting con:

    void _exit(int status) {
        __asm__ __volatile__ ("mov r0, #0x18; ldr r1, =#0x20026; svc 0x00123456");
    }
    

    como se muestra en este ejemplo .

    Por ejemplo, puede redirigir printfa los sistemas UART o ARM, o implementar exit()con semihosting .

  • sistemas operativos integrados como FreeRTOS y Zephyr .

    Dichos sistemas operativos generalmente le permiten desactivar la programación preventiva, lo que le brinda un control total sobre el tiempo de ejecución del programa.

    Pueden verse como una especie de Newlib pre-implementado.

GNU GRUB Multiboot

Los sectores de arranque son simples, pero no son muy convenientes:

  • solo puede tener un sistema operativo por disco
  • el código de carga debe ser realmente pequeño y encajar en 512 bytes
  • tienes que iniciar mucho tu mismo, como pasar al modo protegido

Es por esas razones que GNU GRUB creó un formato de archivo más conveniente llamado multiboot.

Ejemplo de trabajo mínimo: https://github.com/cirosantilli/x86-bare-metal-examples/tree/d217b180be4220a0b4a453f31275d38e697a99e0/multiboot/hello-world

También lo uso en mi repositorio de ejemplos de GitHub para poder ejecutar fácilmente todos los ejemplos en hardware real sin quemar el USB un millón de veces.

Resultado QEMU:

ingrese la descripción de la imagen aquí

T430:

ingrese la descripción de la imagen aquí

Si prepara su sistema operativo como un archivo de arranque múltiple, GRUB podrá encontrarlo dentro de un sistema de archivos normal.

Esto es lo que hacen la mayoría de las distribuciones, colocar las imágenes del sistema operativo /boot.

Los archivos de arranque múltiple son básicamente un archivo ELF con un encabezado especial. GRUB los especifica en: https://www.gnu.org/software/grub/manual/multiboot/multiboot.html

Puede convertir un archivo de arranque múltiple en un disco de arranque con grub-mkrescue.

Firmware

En verdad, su sector de arranque no es el primer software que se ejecuta en la CPU del sistema.

Lo que realmente se ejecuta primero es el llamado firmware , que es un software:

  • hecho por los fabricantes de hardware
  • fuente típicamente cerrada pero probablemente basada en C
  • almacenado en memoria de solo lectura y, por lo tanto, más difícil / imposible de modificar sin el consentimiento del proveedor.

Los firmwares bien conocidos incluyen:

  • BIOS : antiguo firmware x86 totalmente presente. SeaBIOS es la implementación de código abierto predeterminada utilizada por QEMU.
  • UEFI : sucesor de BIOS, mejor estandarizado, pero más capaz e increíblemente hinchado.
  • Coreboot : el noble intento de código abierto de arco cruzado

El firmware hace cosas como:

  • haga un bucle sobre cada disco duro, USB, red, etc. hasta que encuentre algo de arranque.

    Cuando ejecutamos QEMU, -hdadice que main.imges un disco duro conectado al hardware, y hdaes el primero en probarse, y se usa.

  • cargue los primeros 512 bytes en la dirección de memoria RAM 0x7c00, coloque el RIP de la CPU allí y déjelo funcionar

  • mostrar cosas como el menú de inicio o las llamadas de impresión del BIOS en la pantalla

El firmware ofrece una funcionalidad similar a la de un sistema operativo, de la cual dependen la mayoría de los sistemas operativos. Por ejemplo, un subconjunto de Python ha sido portado para ejecutarse en BIOS / UEFI: https://www.youtube.com/watch?v=bYQ_lq5dcvM

Se puede argumentar que los firmwares son indistinguibles de los sistemas operativos, y que el firmware es la única programación "verdadera" de metal desnudo que se puede hacer.

Como dice este desarrollador de CoreOS :

La parte dificil

Cuando enciende una PC, los chips que conforman el conjunto de chips (northbridge, southbridge y SuperIO) aún no se inicializan correctamente. A pesar de que la ROM del BIOS está tan alejada de la CPU como podría estar, la CPU puede acceder a esto, porque tiene que estarlo, de lo contrario la CPU no tendría instrucciones para ejecutar. Esto no significa que la ROM del BIOS esté completamente asignada, generalmente no. Pero solo se asigna lo suficiente para iniciar el proceso de arranque. Cualquier otro dispositivo, solo olvídalo.

Cuando ejecuta Coreboot en QEMU, puede experimentar con las capas superiores de Coreboot y con cargas útiles, pero QEMU ofrece pocas oportunidades para experimentar con el código de inicio de bajo nivel. Por un lado, la RAM solo funciona desde el principio.

Publicar estado inicial del BIOS

Al igual que muchas cosas en el hardware, la estandarización es débil, y una de las cosas en las que no debe confiar es en el estado inicial de los registros cuando su código comienza a ejecutarse después del BIOS.

Hágase un favor y use un código de inicialización como el siguiente: https://stackoverflow.com/a/32509555/895245

Los registros tienen gusto %dsy %estienen efectos secundarios importantes, por lo que debe ponerlos a cero incluso si no los está usando explícitamente.

Tenga en cuenta que algunos emuladores son mejores que el hardware real y le dan un buen estado inicial. Luego, cuando se ejecuta en hardware real, todo se rompe.

El Torito

Formato que se puede grabar en CD: https://en.wikipedia.org/wiki/El_Torito_%28CD-ROM_standard%29

También es posible producir una imagen híbrida que funcione en ISO o USB. Esto se puede hacer con grub-mkrescue( ejemplo ), y también lo hace el kernel de Linux al make isoimageusar isohybrid.

BRAZO

En ARM, las ideas generales son las mismas.

No hay un firmware preinstalado semi estandarizado ampliamente disponible como BIOS para que podamos usar para el IO, por lo que los dos tipos más simples de IO que podemos hacer son:

  • serial, que está ampliamente disponible en devboards
  • parpadea el LED

He subido:

Algunas diferencias de x86 incluyen:

  • IO se realiza por escrito a las direcciones de magia directamente, no hay es iny outlas instrucciones.

    Esto se llama memoria asignada IO .

  • para un hardware real, como Raspberry Pi, puede agregar el firmware (BIOS) usted mismo a la imagen del disco.

    Eso es algo bueno, ya que hace que la actualización de ese firmware sea más transparente.

Recursos

Ciro Santilli 郝海东 冠状 病 六四 事件 法轮功
fuente
3
Los Unikernels son una alternativa para las personas que no pueden / no quieren ir a un nivel tan bajo y aún quieren beneficiarse de su huella muy baja.
AndreLDM
1
@AndreLDM Estaba a punto de agregar las noticias de Unikernel basadas en Linux, pero aún me sentía demasiado nervioso: next.redhat.com/2018/11/14/ukl-a-unikernel-based-on-linux
Ciro Santilli 郝海东 冠状 病六四 事件 法轮功
14
Respuesta realmente detallada pero "un programa que se ejecuta sin un SO, es un SO" no es cierto. Puede escribir un programa que solo enciende / apaga un LED pero que no lo convierte en un sistema operativo. Algunos códigos de firmware que ejecutan el microcontrolador en su unidad flash no lo convierten en un sistema operativo. Un sistema operativo es, como mínimo, una capa de abstracción para escribir otro software más fácilmente. Como mínimo en estos días, diría que si no hay un planificador, es probable que no sea un sistema operativo.
Vitali
44
Buena respuesta, excepto por el sinsentido absoluto de que cualquier programa que no se ejecuta en un sistema operativo es un sistema operativo.
curiousdannii
3
@MichaelPetch hey, solo para guardar el valor nulo en el sector de arranque :-) Probablemente no valga la pena.
Ciro Santilli 郝海东 冠状 病 六四 事件 法轮功
3

Sistema operativo como inspiración

El sistema operativo también es un programa , por lo que también podemos crear nuestro propio programa creando desde cero o cambiando (limitando o agregando) características de uno de los pequeños sistemas operativos , y luego ejecutarlo durante el proceso de arranque (usando una imagen ISO ) .

Por ejemplo, esta página se puede usar como punto de partida:

Cómo escribir un sistema operativo simple

¡Aquí, todo el sistema operativo cabe completamente en un sector de arranque de 512 bytes ( MBR )!

Este sistema operativo simple o similar se puede utilizar para crear un marco simple que nos permita:

haga que el gestor de arranque cargue sectores posteriores en el disco en la RAM y salte a ese punto para continuar la ejecución . O puede leer sobre FAT12, el sistema de archivos utilizado en las unidades de disquete, e implementarlo .

Sin embargo, hay muchas posibilidades. Por ejemplo, para ver un sistema operativo de lenguaje ensamblador x86 más grande , podemos explorar el sistema operativo MykeOS , x86, que es una herramienta de aprendizaje para mostrar el funcionamiento simple de los sistemas operativos en modo real de 16 bits, con código bien comentado y amplia documentación .

Boot Loader como inspiración

Otro tipo común de programas que se ejecutan sin el sistema operativo también son cargadores de arranque . Podemos crear un programa inspirado en dicho concepto, por ejemplo, usando este sitio:

Cómo desarrollar tu propio cargador de arranque

El artículo anterior presenta también la arquitectura básica de tales programas :

  1. Carga correcta a la memoria por 0000: dirección 7C00.
  2. Llamar a la función BootMain que se desarrolla en el lenguaje de alto nivel.
  3. Mostrar "" Hola, mundo ... ", desde el mensaje de bajo nivel" en la pantalla.

Como podemos ver, esta arquitectura es muy flexible y nos permite implementar cualquier programa , no necesariamente un cargador de arranque.

En particular, muestra cómo usar la técnica de "código mixto" gracias a la cual es posible combinar construcciones de alto nivel (de C o C ++ ) con comandos de bajo nivel (de Assembler ). Este es un método muy útil, pero debemos recordar que:

Para compilar el programa y obtener el archivo ejecutable , necesitará el compilador y el enlazador de Assembler para el modo de 16 bits . Para C / C ++ , solo necesitará el compilador que puede crear archivos de objetos para el modo de 16 bits .

El artículo muestra también cómo ver el programa creado en acción y cómo realizar sus pruebas y depuración.

Aplicaciones UEFI como inspiración

Los ejemplos anteriores utilizan el hecho de cargar el sector MBR en el medio de datos. Sin embargo, podemos profundizar en las profundidades, por ejemplo, con las aplicaciones UEFI :

Más allá de cargar un sistema operativo, UEFI puede ejecutar aplicaciones UEFI, que residen como archivos en la partición del sistema EFI. Se pueden ejecutar desde el shell de comandos UEFI, mediante el administrador de arranque del firmware u otras aplicaciones UEFI. Las aplicaciones UEFI se pueden desarrollar e instalar independientemente del fabricante del sistema.

Un tipo de aplicación UEFI es un cargador de sistemas operativos como GRUB, rEFInd, Gummiboot y Windows Boot Manager; que carga un archivo del sistema operativo en la memoria y lo ejecuta. Además, un cargador de SO puede proporcionar una interfaz de usuario para permitir la ejecución de otra aplicación UEFI. Las utilidades como el shell UEFI también son aplicaciones UEFI.

Si nos gustaría comenzar a crear dichos programas , podemos, por ejemplo, comenzar con estos sitios web:

Programación para EFI: Creación de un programa "Hello, World" / Programación UEFI - Primeros pasos

Explorando los problemas de seguridad como inspiración

Es bien sabido que hay un grupo completo de software malicioso (que son programas) que se ejecutan antes de que se inicie el sistema operativo .

Un gran grupo de ellos opera en el sector MBR o aplicaciones UEFI, al igual que todas las soluciones anteriores, pero también hay otras que usan otro punto de entrada, como el Registro de inicio de volumen (VBR) o el BIOS :

Hay al menos cuatro virus de ataque de BIOS conocidos , dos de los cuales fueron con fines de demostración.

o quizás otro también.

Ataques antes del inicio del sistema

Los bootkits han evolucionado desde el desarrollo de prueba de concepto hasta la distribución masiva y ahora se han convertido efectivamente en software de código abierto .

Diferentes formas de arrancar

También creo que en este contexto también vale la pena mencionar que hay varias formas de arrancar el sistema operativo (o el programa ejecutable destinado a esto) . Hay muchos, pero me gustaría prestar atención a cargar el código de la red utilizando la opción Network Boot ( PXE ), que nos permite ejecutar el programa en la computadora independientemente de su sistema operativo e incluso independientemente de cualquier medio de almacenamiento que sea directamente conectado a la computadora:

¿Qué es el arranque de red (PXE) y cómo puede usarlo?

simhumileco
fuente