Firmware Security/lang-es: Difference between revisions
Jump to navigation
Jump to search
RafaelOrtiz (talk | contribs) m (+beginning translation) |
RafaelOrtiz (talk | contribs) m (Redirecting to Firmware Security) |
||
| Line 4: | Line 4: | ||
{{draft}} |
{{draft}} |
||
== Scope == |
== Scope == |
||
{{ Translated text | |
|||
This page describes the role of Open Firmware in BitFrost security on XO. |
This page describes the role of Open Firmware in BitFrost security on XO. |
||
| display = block }} |
|||
== Goals == |
== Goals == |
||
{{ Translated text | |
|||
# Run recovery firmware if primary firmware is bad |
# Run recovery firmware if primary firmware is bad |
||
# No access to ok prompt without developer key |
# No access to ok prompt without developer key |
||
| Line 15: | Line 15: | ||
# Unactivated laptops will only boot the activation image |
# Unactivated laptops will only boot the activation image |
||
# Boot alternate OS image if primary OS image is bad |
# Boot alternate OS image if primary OS image is bad |
||
| display = block }} |
|||
== Files == |
== Files == |
||
{{ Translated text | |
|||
The files listed below are on NAND FLASH in JFFS2. The zip archives listed below must be created without compression (-n option) and without paths (-j option). Implementation notes and rationale are in italics. |
The files listed below are on NAND FLASH in JFFS2. The zip archives listed below must be created without compression (-n option) and without paths (-j option). Implementation notes and rationale are in italics. |
||
| Line 43: | Line 43: | ||
*: ''Security dicates that we boot from an authenticated filesystem. Rather than have OFW authenticate the full USB/SD contents, we'll boot from an authenticated ramdisk, which can then authenticate whatever other files it needs (if any) from the USB/SD disk. For this reason, there should always be a ramdisk, but it may be monolithic with the kernel in runos.zip rather than in a separate runrd.zip file.'' |
*: ''Security dicates that we boot from an authenticated filesystem. Rather than have OFW authenticate the full USB/SD contents, we'll boot from an authenticated ramdisk, which can then authenticate whatever other files it needs (if any) from the USB/SD disk. For this reason, there should always be a ramdisk, but it may be monolithic with the kernel in runos.zip rather than in a separate runrd.zip file.'' |
||
*: ''We should be careful to ensure that the files are authenticated after they have been loaded into memory, to prevent attacks involving switching files between authentication and later use.'' |
*: ''We should be careful to ensure that the files are authenticated after they have been loaded into memory, to prevent attacks involving switching files between authentication and later use.'' |
||
| display = block }} |
|||
== Process == |
== Process == |
||
{{ Translated text | |
|||
# If OFW fails to come up correctly, a firmware recovery procedure is attempted - details TBD. |
# If OFW fails to come up correctly, a firmware recovery procedure is attempted - details TBD. |
||
# In the following, the "primary" images are the files in /boot, and the "secondary" images are the files in /boot-alt, '''unless''' the "check" gamepad key is held down during boot, in which case the roles reverse: the primary files come from /boot-alt, and the secondary files come from /boot. |
# In the following, the "primary" images are the files in /boot, and the "secondary" images are the files in /boot-alt, '''unless''' the "check" gamepad key is held down during boot, in which case the roles reverse: the primary files come from /boot-alt, and the secondary files come from /boot. |
||
| Line 58: | Line 58: | ||
# OFW verifies and boots from the boot files in the secondary directory. |
# OFW verifies and boots from the boot files in the secondary directory. |
||
# If none of the above booting steps succeed, OFW displays and error screen and halts. |
# If none of the above booting steps succeed, OFW displays and error screen and halts. |
||
| display = block }} |
|||
== Usage notes == |
== Usage notes == |
||
{{ Translated text | |
|||
* After boot, userland can determine the source source from the OFW device tree in /ofw/<fill me in>. This can be used to determine whether activation is needed (actos.zip) or whether booting is being performed from the secondary source (boot-alt/*). |
* After boot, userland can determine the source source from the OFW device tree in /ofw/<fill me in>. This can be used to determine whether activation is needed (actos.zip) or whether booting is being performed from the secondary source (boot-alt/*). |
||
* Although outside the scope of this spec, there are primary and secondary filesystem roots in /fsroot and /fsroot-alt corresponding to the kernels in /boot and /boot-alt. /boot/runrd.img will typically be absent to speed boot. However, /boot-alt/runrd.img will typically be required in order to switch to /fsroot-alt so that kernel and userland match. When we clone /boot into /boot-alt at the beginning of an upgrade, we link in an appropriate /boot-alt/runrd.img |
* Although outside the scope of this spec, there are primary and secondary filesystem roots in /fsroot and /fsroot-alt corresponding to the kernels in /boot and /boot-alt. /boot/runrd.img will typically be absent to speed boot. However, /boot-alt/runrd.img will typically be required in order to switch to /fsroot-alt so that kernel and userland match. When we clone /boot into /boot-alt at the beginning of an upgrade, we link in an appropriate /boot-alt/runrd.img |
||
| Line 66: | Line 67: | ||
*# Swap /boot and /boot-alt, making future boots start this kernel. This option is preferred. We should ensure that we've done another upgrade before we try to boot into a different kernel again. |
*# Swap /boot and /boot-alt, making future boots start this kernel. This option is preferred. We should ensure that we've done another upgrade before we try to boot into a different kernel again. |
||
* We will typically use hard or soft links to avoid storing multiple os and ramdisk images. The current plan is to actually have only one kernel and one ramdisk image; the ramdisk will look at how it was invoked to determine whether this is an upgrade, activation, or alternate boot. |
* We will typically use hard or soft links to avoid storing multiple os and ramdisk images. The current plan is to actually have only one kernel and one ramdisk image; the ramdisk will look at how it was invoked to determine whether this is an upgrade, activation, or alternate boot. |
||
| display = block }} |
|||
== Notes == |
== Notes == |
||
{{ Translated text | |
|||
* I am assuming that the primary use of USB/SD boot is to do OS, firmware, or activity upgrades where bandwidth is a limitation. These can easily be done with the mechanism provided by just sticking a (properly signed) "magic upgrade key" into the USB port and power-cycling. |
* I am assuming that the primary use of USB/SD boot is to do OS, firmware, or activity upgrades where bandwidth is a limitation. These can easily be done with the mechanism provided by just sticking a (properly signed) "magic upgrade key" into the USB port and power-cycling. |
||
* USB probing is time-consuming and perilous (although SD is not). At some point (after manufacturing processes are fixed) we'll only try to boot from USB if the 'X' game key is pressed during boot. |
* USB probing is time-consuming and perilous (although SD is not). At some point (after manufacturing processes are fixed) we'll only try to boot from USB if the 'X' game key is pressed during boot. |
||
* We could be more user-friendly by detecting "failed boot after linux kernel invocation" in some way, and automatically booting from the backup in this case. This seems like post-FRS work. |
* We could be more user-friendly by detecting "failed boot after linux kernel invocation" in some way, and automatically booting from the backup in this case. This seems like post-FRS work. |
||
* Firmware RTC *must be UTC*. Quanta must set the RTC to UTC at the factory; antitheft server must sync to UTC during antitheft interaction. |
* Firmware RTC *must be UTC*. Quanta must set the RTC to UTC at the factory; antitheft server must sync to UTC during antitheft interaction. |
||
display = block }} |
|||
[[Category:Missing translation]] |
[[Category:Missing translation]] |
||
Revision as of 23:22, 20 July 2007
Redirect to:
Esta página está supervisada por el equipo de OLPC.
|
NOTE: The contents of this page are not set in stone, and are subject to change! This page is a draft in active flux ... |
|
Scope
This page describes the role of Open Firmware in BitFrost security on XO.
Goals
- Run recovery firmware if primary firmware is bad
- No access to ok prompt without developer key
- Firmware update images must be signed
- Boot images must be signed
- Unactivated laptops will only boot the activation image
- Boot alternate OS image if primary OS image is bad
Files
{{{1}}}
Process
- If OFW fails to come up correctly, a firmware recovery procedure is attempted - details TBD.
- In the following, the "primary" images are the files in /boot, and the "secondary" images are the files in /boot-alt, unless the "check" gamepad key is held down during boot, in which case the roles reverse: the primary files come from /boot-alt, and the secondary files come from /boot.
- OFW checks for a new firmware image in the /boot directory on an attached USB, then SD, device. If one exists and verifies, OFW reflashes itself and reboots.
- Upgrade USB keys may contain firmware-only upgrades.
- OFW checks for a new firmware image in the primary directory in the NAND flash. If one exists and verifies, OFW reflashes itself and reboots.
- OFW locks out further SPI FLASH writing with the hardware lock.
- If a valid developer key is present, OFW enters non-secure mode, where it behaves as it currently does. Otherwise ...
- If the activation key is present and valid (fill in details), the boot filenames will be runos.zip and (if present) runrd.zip. Otherwise, the boot filenames will be actos.zip and (if present) actrd.zip.
- If the activation key is present and valid, we will attempt to verify and boot from the boot files in /boot on an attached USB, then SD, device.
- OFW verifies and boots from the boot files in the primary directory.
- OFW verifies and boots from the boot files in the secondary directory.
- If none of the above booting steps succeed, OFW displays and error screen and halts.
Usage notes
- After boot, userland can determine the source source from the OFW device tree in /ofw/<fill me in>. This can be used to determine whether activation is needed (actos.zip) or whether booting is being performed from the secondary source (boot-alt/*).
- Although outside the scope of this spec, there are primary and secondary filesystem roots in /fsroot and /fsroot-alt corresponding to the kernels in /boot and /boot-alt. /boot/runrd.img will typically be absent to speed boot. However, /boot-alt/runrd.img will typically be required in order to switch to /fsroot-alt so that kernel and userland match. When we clone /boot into /boot-alt at the beginning of an upgrade, we link in an appropriate /boot-alt/runrd.img
- When the alternate kernel is booted and we've switched into /fsroot-alt, we can either:
- add a /boot/runrd.zip link so that if we reboot into the primary we can switch the filesystem back /fsroot, or
- Swap /boot and /boot-alt, making future boots start this kernel. This option is preferred. We should ensure that we've done another upgrade before we try to boot into a different kernel again.
- We will typically use hard or soft links to avoid storing multiple os and ramdisk images. The current plan is to actually have only one kernel and one ramdisk image; the ramdisk will look at how it was invoked to determine whether this is an upgrade, activation, or alternate boot.