¿Cómo ejecutar un programa sin sistema operativo?

Basta ya de investigar en otras páginas porque has llegado al lugar justo, contamos con la respuesta que buscas pero sin complicaciones.

Ejemplos ejecutables

Creemos y ejecutemos algunos programas minúsculos de hello world bare metal que se ejecutan sin un sistema operativo en:

• una computadora portátil Lenovo Thinkpad T430 x86 con firmware UEFI BIOS 1.16
• una Raspberry Pi 3 basada en ARM

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

El código de todos los ejemplos de 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 antiguas que no contienen datos críticos! O incluso mejor, use devboards semi-desechables baratos como Raspberry Pi, vea el ejemplo de ARM a continuación.

Para una computadora portátil 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. dígale que arranque desde el USB.

   Esto significa hacer que el firmware elija 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 encenderlo, es cuando tengo que presionar Enter para ingresar al menú de inicio:

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

Desde allí, puedo seleccionar el USB como dispositivo de arranque de esta manera:

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

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 un solo printf llama:

printf '364%509s125252' > main.img
sudo apt-get install qemu-system-x86
qemu-system-x86_64 -hda main.img

Salir:

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 obtenemos una pantalla en blanco con un cursor parpadeante:

main.img contiene lo siguiente:

• 364 en octal == 0xf4 en hexadecimal: la codificación de un hlt instrucció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 x POSIX 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.

• %509s producir 509 espacios. Necesario completar el archivo hasta el byte 510.

• 125252 en octal == 0x55 seguido por 0xaa.

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

  La BIOS recorre todos nuestros discos buscando los de arranque, y solo considera los de arranque aquellos 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 printf maestro, puede confirmar el contenido de main.img con:

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

dónde 20 es un espacio en ASCII.

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

Hola mundo sector de arranque

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

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

• solicite 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. Se puede utilizar en modo protegido.

• escriba un controlador y hable directamente con el hardware de la pantalla. Ésta es la forma “correcta” de hacerlo: más potente, pero más compleja.

• Puerto serial. Este es un protocolo estandarizado muy simple que envía y recibe caracteres desde un terminal anfitrión.

  En computadoras de escritorio, se ve así:

  

  Fuente.

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

  Esto es realmente una lástima, 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 los suyos semihosting, por ejemplo. En hardware real, requiere algo de 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 en sentido ascendente.

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:

Y en el T430:

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 para el usuario, tenemos:

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

• cli: deshabilita las interrupciones del software. Esos podrían hacer que el procesador comience a funcionar nuevamente después de la hlt

• int $0x10: realiza una llamada al BIOS. Esto es lo que imprime los personajes uno a uno.

Las banderas de enlace importantes son:

• --oformat binary: genera un código ensamblador binario sin procesar, no lo envuelva dentro de un archivo ELF como es el caso de los ejecutables normales del área de usuario.

Para comprender mejor la parte de la secuencia de comandos del vinculador, familiarícese con el paso de reubicación del vínculo: ¿Qué hacen los vinculadores?

Programas más frescos x86 bare metal

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

• multinúcleo: ¿Qué aspecto tiene el lenguaje ensamblador multinúcleo?
• paginación: ¿Cómo funciona la paginación x86?

Utilice C en lugar de ensamblado

Resumen: use GRUB multiboot, que resolverá muchos problemas molestos en los que nunca pensó. Consulte la sección siguiente.

La principal dificultad en x86 es que el BIOS solo carga 512 bytes desde el disco a la memoria, y es probable que aumente esos 512 bytes al usar C!

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

Alternativamente:

• Si solo necesita que funcione en QEMU pero no en hardware real, use el -kernel opción, que carga un archivo ELF completo en la memoria. Aquí hay un ejemplo de ARM que he creado con ese método.
• para Raspberry Pi, el firmware predeterminado se encarga de la carga de la imagen desde un archivo ELF llamado kernel7.img, muy parecido a QEMU -kernel lo hace.

Solo para fines educativos, aquí hay un ejemplo de C mínimo de 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) 
    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: https://stackoverflow.com/questions/16835716/bss-vs-common-what-goes-where */
    *(.bss)
    *(COMMON)
    __bss_end = .;
  
  /* https://stackoverflow.com/questions/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 de C

Sin embargo, las cosas se vuelven más divertidas si también desea usar 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 pasar por un sistema operativo completo como Linux, incluyen:

• Escribe lo tuyo. Al final, son solo un montón de encabezados y archivos C, ¿verdad? ¿¿Derecha??

• Newlib

  Ejemplo detallado en: https://electronics.stackexchange.com/questions/223929/c-standard-libraries-on-bare-metal/223931

  Newlib implementa todas las cosas aburridas que no son específicas del sistema operativo para usted, por ejemplo memcmp, memcpyetc.

  Luego, proporciona algunos códigos auxiliares para que implemente las llamadas al sistema que necesite.

  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 en este ejemplo.

  Por ejemplo, puede redirigir printf a 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 preimplementado.

GNU GRUB Arranque múltiple

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

• solo puede tener un sistema operativo por disco
• el código de carga tiene que ser muy pequeño y caber en 512 bytes
• tienes que iniciar mucho tú mismo, como pasar al modo protegido

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

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:

T430:

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, colocando las imágenes del sistema operativo en /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
• típicamente de código cerrado pero probablemente basado en C
• almacenado en la memoria de solo lectura, y por lo tanto más difícil / imposible de modificar sin el consentimiento del vendedor.

Los firmwares más 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 intento de código abierto de arco cruzado noble

El firmware hace cosas como:

• recorra cada disco duro, USB, red, etc. hasta que encuentre algo de arranque.

  Cuando ejecutamos QEMU, -hda dice que main.img es un disco duro conectado al hardware, y hda es el primero en probarse y se utiliza.

• cargar los primeros 512 bytes en la dirección de la 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 que dependen la mayoría de los sistemas operativos. Por ejemplo, se ha portado un subconjunto de Python para que se ejecute 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" que se puede realizar.

Como dice este desarrollador de CoreOS:

La parte dificil

Cuando enciende una PC, los chips que componen el conjunto de chips (northbridge, southbridge y SuperIO) aún no se inicializan correctamente. A pesar de que la ROM del BIOS está lo más alejada posible de la CPU, la CPU puede acceder a ella, 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, por lo general no. Pero solo se asigna lo suficiente para que el proceso de arranque comience. Cualquier otro dispositivo, 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 simplemente funciona desde el principio.

Estado inicial posterior al BIOS

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

Así que hágase un favor y utilice un código de inicialización como el siguiente: https://stackoverflow.com/a/32509555/895245

Se registra como %ds y %es tienen efectos secundarios importantes, por lo que debe eliminarlos incluso si no los está utilizando explícitamente.

Tenga en cuenta que algunos emuladores son más agradables que el hardware real y le brindan 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 en make isoimage utilizando isohybrid.

BRAZO

En ARM, las ideas generales son las mismas.

No existe un firmware preinstalado semi-estandarizado ampliamente disponible como BIOS para que lo usemos 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
• hacer parpadear el LED

He subido:

• algunos ejemplos simples de QEMU C + Newlib y ensamblados sin procesar aquí en GitHub.

  El ejemplo de prompt.c, por ejemplo, toma la entrada de su terminal host y devuelve la salida a través del UART simulado:

  enter a character
  got: a
  new alloc of 1 bytes at address 0x0x4000a1c0
  enter a character
  got: b
  new alloc of 2 bytes at address 0x0x4000a1c0
  enter a character
  

  Consulte también: ¿Cómo crear programas ARM sin sistema operativo y ejecutarlos en QEMU?

• una configuración de luz intermitente Raspberry Pi totalmente automatizada en: https://github.com/cirosantilli/raspberry-pi-bare-metal-blinker

  

  Ver también: ¿Cómo ejecutar un programa C sin sistema operativo en la Raspberry Pi?

  Para "ver" los LED en QEMU, debe compilar QEMU desde la fuente con un indicador de depuración: https://raspberrypi.stackexchange.com/questions/56373/is-it-possible-to-get-the-state-of- los-leds-y-gpios-en-una-emulación-qemu-like-t

  A continuación, deberías probar un hello world de UART. Puede comenzar desde el ejemplo del intermitente y reemplazar el kernel con este: https://github.com/dwelch67/raspberrypi/tree/bce377230c2cdd8ff1e40919fdedbc2533ef5a00/uart01

  Primero haga que el UART funcione con Raspbian como lo expliqué en: https://raspberrypi.stackexchange.com/questions/38/prepare-for-ssh-without-a-screen/54394#54394 Se verá algo como esto:

  

  Asegúrese de usar los pines correctos, o de lo contrario puede quemar su convertidor UART a USB, ya lo he hecho dos veces por cortocircuito a tierra y 5V ...

  Finalmente conéctese al serial desde el host con:

  screen /dev/ttyUSB0 115200
  

  Para la Raspberry Pi, usamos una tarjeta Micro SD en lugar de una memoria USB para contener nuestro ejecutable, para lo cual normalmente necesita un adaptador para conectarse a su computadora:

  

  No olvide desbloquear el adaptador SD como se muestra en: https://askubuntu.com/questions/213889/microsd-card-is-set-to-read-only-state-how-can-i-write-data -en-él / 814585 # 814585

  https://github.com/dwelch67/raspberrypi parece el tutorial de Raspberry Pi bare metal más popular disponible en la actualidad.

Algunas diferencias con x86 incluyen:

• IO se realiza escribiendo directamente a direcciones mágicas, no hay in y out instrucciones.

  A esto se le llama E / S mapeada en memoria.

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

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

Recursos

• http://wiki.osdev.org es un estupendo fuente para esos asuntos.
• https://github.com/scanlime/metalkit es un sistema de compilación bare metal más automatizado / general, que proporciona una pequeña API personalizada

¿Cómo se ejecuta un programa por sí solo sin que se ejecute un sistema operativo?

Coloca su código binario en un lugar donde el procesador busca después de reiniciar (por ejemplo, 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 la denomina "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 en particular ... Esto es algo que los cargadores de arranque suelen hacer, 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 te 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án la mayoría de sus preguntas http://wiki.osdev.org/Introduction

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

Sistema operativo como inspiración

El sistema operativo también es un programa, entonces también podemos cree nuestro propio programa creando desde cero o cambiando (limitando o agregando) características de una de las pequeños sistemas operativos, y luego ejecutarlo durante el proceso de arranque (usando un Imagen ISO).

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

Cómo escribir un sistema operativo simple

Aquí el ¡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:

hacer el cargador de arranque carga los sectores subsiguientes del disco en la RAM y salta a ese punto para continuar con la ejecución. O podrías leer en FAT12, el sistema de archivos utilizado en las unidades de disquete, e implementarlo.

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

Boot Loader como inspiración

Otro tipo común de Los programas que se ejecutan sin el sistema operativo también son Boot Loaders.. Podemos crear un programa inspirado en tal 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. Corrija la carga en la memoria por la dirección 0000: 7C00.
2. Llamar a la función BootMain que se desarrolla en el lenguaje de alto nivel.
3. Muestre el mensaje “” Hola, mundo… ”, desde el nivel bajo” 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 utilizar el técnica de "código mixto" gracias a lo cual es posible combinar construcciones de alto nivel (de C o C ++) con comandos de bajo nivel (de Ensamblador). Este es un método muy útil, pero debemos recordar que:

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

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

Aplicaciones UEFI como inspiración

Los ejemplos anteriores utilizaron el hecho de cargar el sector MBR en el soporte de datos. Sin embargo, podemos adentrarnos más en las profundidades jugando, por ejemplo, con el UEFI aplicaciones:

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 o mediante otras aplicaciones UEFI. Las aplicaciones UEFI se pueden desarrollar e instalar independientemente del fabricante del sistema.

Un tipo de aplicación UEFI es una Cargador de SO 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 que se ejecute la selección de otra aplicación UEFI. Las utilidades como UEFI shell también son aplicaciones UEFI.

Si quisiéramos para comenzar a crear tales 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

Explorar los problemas de seguridad como inspiración

Es bien sabido que hay todo un grupo de software malicioso (que son programas) que se están ejecutando 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 aquellos que usan otro punto de entrada como Volume Boot Record (VBR) o 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

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. para cargar el código de la red usando 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 está conectado directamente a la computadora:

¿Qué es el arranque en red (PXE) y cómo se puede utilizar?

---

---

Utiliza Nuestro Buscador