mirror of
https://github.com/AetherDroid/android_kernel_samsung_on5xelte.git
synced 2025-09-05 16:07:46 -04:00
Fixed MTP to work with TWRP
This commit is contained in:
awab228
commit
f6dfaef42e
50820 changed files with 20846062 additions and 0 deletions
210
Documentation/intel_txt.txt
Normal file
210
Documentation/intel_txt.txt
Normal file
|
|
@ -0,0 +1,210 @@
|
|||
Intel(R) TXT Overview:
|
||||
=====================
|
||||
|
||||
Intel's technology for safer computing, Intel(R) Trusted Execution
|
||||
Technology (Intel(R) TXT), defines platform-level enhancements that
|
||||
provide the building blocks for creating trusted platforms.
|
||||
|
||||
Intel TXT was formerly known by the code name LaGrande Technology (LT).
|
||||
|
||||
Intel TXT in Brief:
|
||||
o Provides dynamic root of trust for measurement (DRTM)
|
||||
o Data protection in case of improper shutdown
|
||||
o Measurement and verification of launched environment
|
||||
|
||||
Intel TXT is part of the vPro(TM) brand and is also available some
|
||||
non-vPro systems. It is currently available on desktop systems
|
||||
based on the Q35, X38, Q45, and Q43 Express chipsets (e.g. Dell
|
||||
Optiplex 755, HP dc7800, etc.) and mobile systems based on the GM45,
|
||||
PM45, and GS45 Express chipsets.
|
||||
|
||||
For more information, see http://www.intel.com/technology/security/.
|
||||
This site also has a link to the Intel TXT MLE Developers Manual,
|
||||
which has been updated for the new released platforms.
|
||||
|
||||
Intel TXT has been presented at various events over the past few
|
||||
years, some of which are:
|
||||
LinuxTAG 2008:
|
||||
http://www.linuxtag.org/2008/en/conf/events/vp-donnerstag.html
|
||||
TRUST2008:
|
||||
http://www.trust-conference.eu/downloads/Keynote-Speakers/
|
||||
3_David-Grawrock_The-Front-Door-of-Trusted-Computing.pdf
|
||||
IDF, Shanghai:
|
||||
http://www.prcidf.com.cn/index_en.html
|
||||
IDFs 2006, 2007 (I'm not sure if/where they are online)
|
||||
|
||||
Trusted Boot Project Overview:
|
||||
=============================
|
||||
|
||||
Trusted Boot (tboot) is an open source, pre-kernel/VMM module that
|
||||
uses Intel TXT to perform a measured and verified launch of an OS
|
||||
kernel/VMM.
|
||||
|
||||
It is hosted on SourceForge at http://sourceforge.net/projects/tboot.
|
||||
The mercurial source repo is available at http://www.bughost.org/
|
||||
repos.hg/tboot.hg.
|
||||
|
||||
Tboot currently supports launching Xen (open source VMM/hypervisor
|
||||
w/ TXT support since v3.2), and now Linux kernels.
|
||||
|
||||
|
||||
Value Proposition for Linux or "Why should you care?"
|
||||
=====================================================
|
||||
|
||||
While there are many products and technologies that attempt to
|
||||
measure or protect the integrity of a running kernel, they all
|
||||
assume the kernel is "good" to begin with. The Integrity
|
||||
Measurement Architecture (IMA) and Linux Integrity Module interface
|
||||
are examples of such solutions.
|
||||
|
||||
To get trust in the initial kernel without using Intel TXT, a
|
||||
static root of trust must be used. This bases trust in BIOS
|
||||
starting at system reset and requires measurement of all code
|
||||
executed between system reset through the completion of the kernel
|
||||
boot as well as data objects used by that code. In the case of a
|
||||
Linux kernel, this means all of BIOS, any option ROMs, the
|
||||
bootloader and the boot config. In practice, this is a lot of
|
||||
code/data, much of which is subject to change from boot to boot
|
||||
(e.g. changing NICs may change option ROMs). Without reference
|
||||
hashes, these measurement changes are difficult to assess or
|
||||
confirm as benign. This process also does not provide DMA
|
||||
protection, memory configuration/alias checks and locks, crash
|
||||
protection, or policy support.
|
||||
|
||||
By using the hardware-based root of trust that Intel TXT provides,
|
||||
many of these issues can be mitigated. Specifically: many
|
||||
pre-launch components can be removed from the trust chain, DMA
|
||||
protection is provided to all launched components, a large number
|
||||
of platform configuration checks are performed and values locked,
|
||||
protection is provided for any data in the event of an improper
|
||||
shutdown, and there is support for policy-based execution/verification.
|
||||
This provides a more stable measurement and a higher assurance of
|
||||
system configuration and initial state than would be otherwise
|
||||
possible. Since the tboot project is open source, source code for
|
||||
almost all parts of the trust chain is available (excepting SMM and
|
||||
Intel-provided firmware).
|
||||
|
||||
How Does it Work?
|
||||
=================
|
||||
|
||||
o Tboot is an executable that is launched by the bootloader as
|
||||
the "kernel" (the binary the bootloader executes).
|
||||
o It performs all of the work necessary to determine if the
|
||||
platform supports Intel TXT and, if so, executes the GETSEC[SENTER]
|
||||
processor instruction that initiates the dynamic root of trust.
|
||||
- If tboot determines that the system does not support Intel TXT
|
||||
or is not configured correctly (e.g. the SINIT AC Module was
|
||||
incorrect), it will directly launch the kernel with no changes
|
||||
to any state.
|
||||
- Tboot will output various information about its progress to the
|
||||
terminal, serial port, and/or an in-memory log; the output
|
||||
locations can be configured with a command line switch.
|
||||
o The GETSEC[SENTER] instruction will return control to tboot and
|
||||
tboot then verifies certain aspects of the environment (e.g. TPM NV
|
||||
lock, e820 table does not have invalid entries, etc.).
|
||||
o It will wake the APs from the special sleep state the GETSEC[SENTER]
|
||||
instruction had put them in and place them into a wait-for-SIPI
|
||||
state.
|
||||
- Because the processors will not respond to an INIT or SIPI when
|
||||
in the TXT environment, it is necessary to create a small VT-x
|
||||
guest for the APs. When they run in this guest, they will
|
||||
simply wait for the INIT-SIPI-SIPI sequence, which will cause
|
||||
VMEXITs, and then disable VT and jump to the SIPI vector. This
|
||||
approach seemed like a better choice than having to insert
|
||||
special code into the kernel's MP wakeup sequence.
|
||||
o Tboot then applies an (optional) user-defined launch policy to
|
||||
verify the kernel and initrd.
|
||||
- This policy is rooted in TPM NV and is described in the tboot
|
||||
project. The tboot project also contains code for tools to
|
||||
create and provision the policy.
|
||||
- Policies are completely under user control and if not present
|
||||
then any kernel will be launched.
|
||||
- Policy action is flexible and can include halting on failures
|
||||
or simply logging them and continuing.
|
||||
o Tboot adjusts the e820 table provided by the bootloader to reserve
|
||||
its own location in memory as well as to reserve certain other
|
||||
TXT-related regions.
|
||||
o As part of its launch, tboot DMA protects all of RAM (using the
|
||||
VT-d PMRs). Thus, the kernel must be booted with 'intel_iommu=on'
|
||||
in order to remove this blanket protection and use VT-d's
|
||||
page-level protection.
|
||||
o Tboot will populate a shared page with some data about itself and
|
||||
pass this to the Linux kernel as it transfers control.
|
||||
- The location of the shared page is passed via the boot_params
|
||||
struct as a physical address.
|
||||
o The kernel will look for the tboot shared page address and, if it
|
||||
exists, map it.
|
||||
o As one of the checks/protections provided by TXT, it makes a copy
|
||||
of the VT-d DMARs in a DMA-protected region of memory and verifies
|
||||
them for correctness. The VT-d code will detect if the kernel was
|
||||
launched with tboot and use this copy instead of the one in the
|
||||
ACPI table.
|
||||
o At this point, tboot and TXT are out of the picture until a
|
||||
shutdown (S<n>)
|
||||
o In order to put a system into any of the sleep states after a TXT
|
||||
launch, TXT must first be exited. This is to prevent attacks that
|
||||
attempt to crash the system to gain control on reboot and steal
|
||||
data left in memory.
|
||||
- The kernel will perform all of its sleep preparation and
|
||||
populate the shared page with the ACPI data needed to put the
|
||||
platform in the desired sleep state.
|
||||
- Then the kernel jumps into tboot via the vector specified in the
|
||||
shared page.
|
||||
- Tboot will clean up the environment and disable TXT, then use the
|
||||
kernel-provided ACPI information to actually place the platform
|
||||
into the desired sleep state.
|
||||
- In the case of S3, tboot will also register itself as the resume
|
||||
vector. This is necessary because it must re-establish the
|
||||
measured environment upon resume. Once the TXT environment
|
||||
has been restored, it will restore the TPM PCRs and then
|
||||
transfer control back to the kernel's S3 resume vector.
|
||||
In order to preserve system integrity across S3, the kernel
|
||||
provides tboot with a set of memory ranges (RAM and RESERVED_KERN
|
||||
in the e820 table, but not any memory that BIOS might alter over
|
||||
the S3 transition) that tboot will calculate a MAC (message
|
||||
authentication code) over and then seal with the TPM. On resume
|
||||
and once the measured environment has been re-established, tboot
|
||||
will re-calculate the MAC and verify it against the sealed value.
|
||||
Tboot's policy determines what happens if the verification fails.
|
||||
Note that the c/s 194 of tboot which has the new MAC code supports
|
||||
this.
|
||||
|
||||
That's pretty much it for TXT support.
|
||||
|
||||
|
||||
Configuring the System:
|
||||
======================
|
||||
|
||||
This code works with 32bit, 32bit PAE, and 64bit (x86_64) kernels.
|
||||
|
||||
In BIOS, the user must enable: TPM, TXT, VT-x, VT-d. Not all BIOSes
|
||||
allow these to be individually enabled/disabled and the screens in
|
||||
which to find them are BIOS-specific.
|
||||
|
||||
grub.conf needs to be modified as follows:
|
||||
title Linux 2.6.29-tip w/ tboot
|
||||
root (hd0,0)
|
||||
kernel /tboot.gz logging=serial,vga,memory
|
||||
module /vmlinuz-2.6.29-tip intel_iommu=on ro
|
||||
root=LABEL=/ rhgb console=ttyS0,115200 3
|
||||
module /initrd-2.6.29-tip.img
|
||||
module /Q35_SINIT_17.BIN
|
||||
|
||||
The kernel option for enabling Intel TXT support is found under the
|
||||
Security top-level menu and is called "Enable Intel(R) Trusted
|
||||
Execution Technology (TXT)". It is considered EXPERIMENTAL and
|
||||
depends on the generic x86 support (to allow maximum flexibility in
|
||||
kernel build options), since the tboot code will detect whether the
|
||||
platform actually supports Intel TXT and thus whether any of the
|
||||
kernel code is executed.
|
||||
|
||||
The Q35_SINIT_17.BIN file is what Intel TXT refers to as an
|
||||
Authenticated Code Module. It is specific to the chipset in the
|
||||
system and can also be found on the Trusted Boot site. It is an
|
||||
(unencrypted) module signed by Intel that is used as part of the
|
||||
DRTM process to verify and configure the system. It is signed
|
||||
because it operates at a higher privilege level in the system than
|
||||
any other macrocode and its correct operation is critical to the
|
||||
establishment of the DRTM. The process for determining the correct
|
||||
SINIT ACM for a system is documented in the SINIT-guide.txt file
|
||||
that is on the tboot SourceForge site under the SINIT ACM downloads.
|
||||
Loading…
Add table
Add a link
Reference in a new issue