https://issuu.com/alabarga/docs/hacker_s_manual_2015_-_power_up_you/1
PAGE 81
Here is what happens in a minimal system boot:
A typical small ARM-style system doesn't have a 'BIOS' or 'EFI' or anything on it. When you 'turn on' the system then voltage is applied to the 'SoC' and the processor immediately begins executing any code that may exist at address 0x0 (or 0x8000 or whatever it is for that particular processor). This corresponds to physical traces on the motherboard and a flash chip.
That flash will be programmed with your 'Boot loader'. You see the SoC doesn't understand how the hardware is configured or anything like that. It doesn't know what the pins on the processor does or how to use main memory. It doesn't know how to read your SD card or turn on a network interface or anything like that. The bootloader must actually program the low-level interfaces on the SoC to even begin to be using memory or anything like that. As a programmer it would be your job to know how to flip the bits and detect memory so that the computer can begin using it. Then whatever storage device you want to use for the OS.. you have to configure that also. Just a minimal amount to activate the larger storage device and load and execute the Linux kernel.
So a operating system doesn't actually need any sort of 'firmware' at all. There is no absolute need for a BIOS or EUFI or anything like that. The Linux kernel itself can do all the configuration that is necessary, but you need something very specific to that mainboard that knows how to do the lowest levels of configuration.. which is what coreboot is for.
Which is why on your ARM-based phone or MIPS router or whatever you can 'brick' it by a doing a bad bootloader flash. Without a functioning bootloader there is no way to interact with the hardware. (Although modern systems are incorporating more features to avoid these problems and make it more friendly to ham-fisted firmware updaters)
The BIOS originally was developed as a sort of ghetto operating system.
It was designed for a era were you didn't have operating systems. You had single-task machines that when they booted they just launched a single application.
The BIOS then provided a set of functions and resources that applications could use to run. It had some fonts, CGA graphics API, ability to read floppy drives and that sort of thing.
The BIOS really is a API of sorts.
Cracking and cloning the BIOS was a huge step forward for PC systems because for the first time it allowed applications written for one PC to be executed successfully on a PC clone.
Later on people produced disk operating systems... which all they did was provide a file system for managing files on a disk. MS-DOS was one of many for x86 systems, but many other types of architectures had DOS systems as well.
When Microsoft finally started coming out with real operating systems like Windows 95 for the PC the BIOS was used for boot strapping the OS.
The x86 'bootloader' is then really a x86 BIOS program used to launch OSes. Of course Windows 95 wasn't that smart so you still relied on the BIOS to configure bits and pieces of hardware.
Later on, of course, you had things like ACPI so that the OS had a standardized way to interact with the hardware for power management among other things.
So with x86 you had a sort of 'dual OS' thing going were you had this stupid ghetto OS people referred to as the 'BIOS' or 'Firmware' and then the real OS for running applications.
The BIOSes typically are kinda shit. They are going to be specific to specific hardware, but typically how they are programmed is that they are copy and pasted from older mainboard designs and then screwed around with until they boot windows. So in your BIOS-based x86 system you will have lots of bastardized code that is floating around that is designed to run hardware from 20 years ago.
This sort of thing is why Linux kernel programmers have to spend a great deal of time 'undoing' the damage caused to your system by it's BIOS.
These sorts of things have some benefits, of course. When you load a OS and bootloader for x86 the hardware is 'made generic' through the use of the BIOS. If you ever tried to build your own OS for a smart phone you'd realize that you need to program and build the kernel and bootloader for that specific device... that is a kernel/bootloader from a different system won't work because the hardware is different. With X86 systems the BIOS hides the details and allows a single binary bootloader and kernel to easily work across a wide variety of systems.
UEFI, is then, a modernized BIOS. Instead of having a mixture of ancient x86 machine code and assembly written by retarded monkeys they have much more 'modern' approach.
It is much more sophisticated and flexible. It has it's own programming languages and interpreters. Firmware on UEFI-enabled devices like video cards can load their own 'drivers' that allow them to be used directly by UEFI.
All sorts of crap like that.
Which is why now you can have these really fancy 'graphical' EUFI configuration screens. The UEFI firmware on your peripheral devices can provide rich interfaces for how to interact with the hardware.
Unfortunately this means that it's extremely complicated and big. The firmware is now as big and complicated as a full-fledged OS.
Complicated and big is bad. This means more bugs. Some bugs are security bugs so more bugs means more security holes. Also it's generally proprietary so you have different groups of people trying to write the same thing from scratch so they can inject their 'secret sauce'. So now not only you have something that is big and buggy, but also has lots of different sets of unique bugs.
But it still allows Microsoft to crank out one binary that works generically across a bunch of different hardware.
Also it allows for a lot of fancy new ways to manage your hardware independently of the OS. Which while often convenient it is also going to be full of bugs and is proprietary. Which is going to be especially bad when the UEFI stuff allows for remote configuration and will piggy back on your network interfaces and doesn't go away completely when the real OS is loaded.
edit:
Thank you for the reddit gold very much.
https://www.reddit.com/r/linux/comments/37c38l/uefi_backdoor_allows_root_exploit_in_linux/
PAGE 81
Here is what happens in a minimal system boot:
A typical small ARM-style system doesn't have a 'BIOS' or 'EFI' or anything on it. When you 'turn on' the system then voltage is applied to the 'SoC' and the processor immediately begins executing any code that may exist at address 0x0 (or 0x8000 or whatever it is for that particular processor). This corresponds to physical traces on the motherboard and a flash chip.
That flash will be programmed with your 'Boot loader'. You see the SoC doesn't understand how the hardware is configured or anything like that. It doesn't know what the pins on the processor does or how to use main memory. It doesn't know how to read your SD card or turn on a network interface or anything like that. The bootloader must actually program the low-level interfaces on the SoC to even begin to be using memory or anything like that. As a programmer it would be your job to know how to flip the bits and detect memory so that the computer can begin using it. Then whatever storage device you want to use for the OS.. you have to configure that also. Just a minimal amount to activate the larger storage device and load and execute the Linux kernel.
So a operating system doesn't actually need any sort of 'firmware' at all. There is no absolute need for a BIOS or EUFI or anything like that. The Linux kernel itself can do all the configuration that is necessary, but you need something very specific to that mainboard that knows how to do the lowest levels of configuration.. which is what coreboot is for.
Which is why on your ARM-based phone or MIPS router or whatever you can 'brick' it by a doing a bad bootloader flash. Without a functioning bootloader there is no way to interact with the hardware. (Although modern systems are incorporating more features to avoid these problems and make it more friendly to ham-fisted firmware updaters)
The BIOS originally was developed as a sort of ghetto operating system.
It was designed for a era were you didn't have operating systems. You had single-task machines that when they booted they just launched a single application.
The BIOS then provided a set of functions and resources that applications could use to run. It had some fonts, CGA graphics API, ability to read floppy drives and that sort of thing.
The BIOS really is a API of sorts.
Cracking and cloning the BIOS was a huge step forward for PC systems because for the first time it allowed applications written for one PC to be executed successfully on a PC clone.
Later on people produced disk operating systems... which all they did was provide a file system for managing files on a disk. MS-DOS was one of many for x86 systems, but many other types of architectures had DOS systems as well.
When Microsoft finally started coming out with real operating systems like Windows 95 for the PC the BIOS was used for boot strapping the OS.
The x86 'bootloader' is then really a x86 BIOS program used to launch OSes. Of course Windows 95 wasn't that smart so you still relied on the BIOS to configure bits and pieces of hardware.
Later on, of course, you had things like ACPI so that the OS had a standardized way to interact with the hardware for power management among other things.
So with x86 you had a sort of 'dual OS' thing going were you had this stupid ghetto OS people referred to as the 'BIOS' or 'Firmware' and then the real OS for running applications.
The BIOSes typically are kinda shit. They are going to be specific to specific hardware, but typically how they are programmed is that they are copy and pasted from older mainboard designs and then screwed around with until they boot windows. So in your BIOS-based x86 system you will have lots of bastardized code that is floating around that is designed to run hardware from 20 years ago.
This sort of thing is why Linux kernel programmers have to spend a great deal of time 'undoing' the damage caused to your system by it's BIOS.
These sorts of things have some benefits, of course. When you load a OS and bootloader for x86 the hardware is 'made generic' through the use of the BIOS. If you ever tried to build your own OS for a smart phone you'd realize that you need to program and build the kernel and bootloader for that specific device... that is a kernel/bootloader from a different system won't work because the hardware is different. With X86 systems the BIOS hides the details and allows a single binary bootloader and kernel to easily work across a wide variety of systems.
UEFI, is then, a modernized BIOS. Instead of having a mixture of ancient x86 machine code and assembly written by retarded monkeys they have much more 'modern' approach.
It is much more sophisticated and flexible. It has it's own programming languages and interpreters. Firmware on UEFI-enabled devices like video cards can load their own 'drivers' that allow them to be used directly by UEFI.
All sorts of crap like that.
Which is why now you can have these really fancy 'graphical' EUFI configuration screens. The UEFI firmware on your peripheral devices can provide rich interfaces for how to interact with the hardware.
Unfortunately this means that it's extremely complicated and big. The firmware is now as big and complicated as a full-fledged OS.
Complicated and big is bad. This means more bugs. Some bugs are security bugs so more bugs means more security holes. Also it's generally proprietary so you have different groups of people trying to write the same thing from scratch so they can inject their 'secret sauce'. So now not only you have something that is big and buggy, but also has lots of different sets of unique bugs.
But it still allows Microsoft to crank out one binary that works generically across a bunch of different hardware.
Also it allows for a lot of fancy new ways to manage your hardware independently of the OS. Which while often convenient it is also going to be full of bugs and is proprietary. Which is going to be especially bad when the UEFI stuff allows for remote configuration and will piggy back on your network interfaces and doesn't go away completely when the real OS is loaded.
edit:
Thank you for the reddit gold very much.
https://www.reddit.com/r/linux/comments/37c38l/uefi_backdoor_allows_root_exploit_in_linux/
No comments:
Post a Comment