An open API service indexing awesome lists of open source software.

https://github.com/3mdeb/oslo

OSLO - Open Secure LOader http://os.inf.tu-dresden.de/~kauer/oslo/
https://github.com/3mdeb/oslo

Last synced: 5 months ago
JSON representation

OSLO - Open Secure LOader http://os.inf.tu-dresden.de/~kauer/oslo/

Awesome Lists containing this project

README

          

OSLO - Open Secure LOader

Bernhard Kauer
_kauer@tudos.org_

Introduction
############

OSLO, the Open Secure Loader, is a boot loader which uses the _skinit_
instruction for authenticated booting.

With around 1000 lines of code and a binary which is in the order
of 4k auditing, bugfixing and in the end trusting OSLO should be
possible.

Prerequisites
=============

To use OSLO a PC platform supporting _skinit_ is needed. There must be
a processor supporting the _skinit_ instruction, a v1.2 TPM [TPM] and
a chipset which provides memory protection for the secure loader.

The _skinit_ instruction is available with newer AMD64 processors
[AMD] and used to create a dynamic root of trust for measurement. It
is a replacement for the static root of trust provided by the BIOS and
subsequent secure boot loaders which are used on machines not
supporting skinit.

Functionality
=============

OSLO is started as kernel from a multi-boot compliant [MBI] loader. It
initialize the TPM, calls skinit, hashes [SHA] every module it gets
from the parent boot-loader and starts the first module as new kernel
in the multi-boot way.

Minimal
=======

Since OSLO is the root of trust of the secure system it is as minimized
as possible. Therefore it neither contain code to load images from
network nor hard disk. This can be done by another untrusted multi-boot
loader like GRUB or syslinux.

Components
##########

:asm.S:
Initialize the processor on startup and after skinit by e.g. loading the
stack pointer and segments.

:sha.c:
A size optimized Sha1 [SHA] implementation which can hash up to 512 MB.
Needs around 512 byte but is nearly 4 times slower than a speed
optimized version. Since boot loading is not performance critical
and OSLO should not hash large amount of data the speed/size
tradeoff is acceptable here.

:tis.c:
A simple TIS [TIS] driver using the memory mapped interface of
version 1.2 TPMs. Tested with TPMs from Infineon, STM, Atmel and
Broadcom.

:tpm.c:
The needed TPM functions, like TPM_Extend.

:elf.c:
The elf decoding.

:osl.c:
The main program including hashing the modules and
startup of the first one.

:util.c asm.h:
Helper functions for string output and low level hardware access
like _rdmsr_.

:mp.c mp.h:
Helper functions to start and stop processors on an MP system.

:beirut.c:
A helper program that hashes the command line of other multiboot
modules.

:pamplona.c:
A helper program that does everything to reverse the steps done by
OSLO. For example it removes DEV protection and clears the global
interrupt flag. It does allow you to use OSLO but start an
unmodified OS in an unsecure way after that.

:munich.c:
A helper program to start Linux [LBP] from a multiboot compliant
loader. The first module is used as linux kernel. The optional
second one is used as initrd.

FAQ
###

: Why is DEV protection not implemented? :
Mainly time reasons and the realization that the workaround for the
DEV init race has to be implemented.

: Why do you extend the PCR for every module? :
Previously, OSLO would calc a hash over all multiboot modules. This
was a bug since hashing one module or hashing two halves of the same
binary with two modules was indistinguishable. The hole between the
two halves could be used by an attacker to hide untrusted code.

: Why do you implemented Beirut? :
There are applications which can be fooled by giving them a faked
commandline. Since someone decided not to fix the applications
and handle untrusted command lines like untrusted config files
(e.g. simple hash them itself), we have to hash the commandline
before we pass it to them. Or in other words: Beirut is just a nasty
hack for compatibility reasons.

: Is OSLO bugfree? :
Of course not in this version. Currently at least two bugs are
known: The DEV initialization is missing and the famous "type of
memory" bug is still present.

References
##########

:AMD: AMD64 Architecture Programmer's Manual Vol. 2 - http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24593.pdf
:LBP: Linux/I386 Boot Protocol - http://lxr.linux.no/source/Documentation/i386/boot.txt
:MBI: multiboot specification - http://www.gnu.org/software/grub/manual/multiboot/multiboot.txt
:SHA: US Secure Hash Algorithm 1 (SHA1) - http://www.ietf.org/rfc/rfc3174.txt
:TIS: TPM Interface Specification - https://www.trustedcomputinggroup.org/groups/pc_client/TCG_PCClientTPMSpecification_1-20_1-00_FINAL.pdf
:TPM: TCG TPM Specification v1.2 rev 5 Part 3 Commands - https://www.trustedcomputinggroup.org/groups/tpm/mainP3Commands_rev85.zip

Acknowledgements
################

OSLO was funded by OpenTC. Special thanks go to AMD Dresden for the
constant support and Infineon Munich for the help with TPMs.