Wednesday, September 25, 2013

A Few Thoughts on Cryptographic Engineering: On the NSA

A Few Thoughts on Cryptographic Engineering: On the NSA: Let me tell you the story of my tiny brush with the biggest crypto story of the year . A few weeks ago I received a call from a reporter a...

Friday, September 13, 2013

[Linux] Learning Linux for embedded systems

Ref: http://www.embedded.com/electronics-blogs/open-mike/4420567/Learning-Linux-for-embedded-systems

Learning Linux for embedded systems

I was recently asked how a person with experience in embedded systems programming with 8-bit processors, such as PIC, as well as 32-bit processors, such as PowerPC, but no Linux experience, can learn how to use Embedded Linux.

What I always recommend to such an embedded systems programmer is this: Look at Embedded Linux as two parts, the embedded part and the Linux part. Let's consider the Linux part first.

The Linux side
Operating systems abound and the choices are many for an embedded system, both proprietary and open source. Linux is one of these choices. No matter what you use for your development host, whether Linux or Windows or Mac, you need to learn how to program using the target OS. In this respect, using Embedded Linux is not greatly different from using VXworks, WindowCE, or another OS. You need an understanding of how the OS is designed, how to configure the OS, and how to program using its application programming interface (API).

A few factors make learning how to program Linux easier than other embedded OSes. You'll find many books and tutorials about Linux, as well as Unix from which it is derived -- many more than for other OSes. Online resources for Linux are ample, while other OSes have a much smaller presence, or one driven by the OS manufacturer. Linux is open source, and you can read the code to get an understanding of exactly what the OS is doing, something that is often impossible with a proprietary OS distributed as binaries. (I certainly do not recommend reading Linux source to try to learn how to program Linux. That's like trying to learn to drive by studying how a car's transmission works.)

The most significant factor that sets Linux apart from other OSes is that the same kernel is used for all systems, from the smallest embedded boards, to desktop systems, to large server farms. This means that you can learn a large amount of Linux programming on your desktop in an environment, which is much more flexible than using a target board with all of the complexities of connecting to the target, downloading a test programming, and running the test. All of the basic concepts and most APIs are the same for your desktop Linux and your Embedded Linux.

Installing Linux
You could install a desktop Linux distribution on your development system, replacing your Windows or Mac system, but that may be a pretty large piece to bite off at one time, since you would likely need to configure email, learn new tools, and come up to speed with a different desktop interface. You could install Linux in a dual-boot environment, where you use the old environment for email, etc., and use the Linux system for learning. This can be pretty awkward, since you need to shut down one environment to bring up the other. Additionally, doing either within a corporate environment may be impractical or impossible. IT folks prefer supporting a known environment, not one that you have chosen.

An easier way is to create a virtual machine environment on your current development system. For Windows hosts, you can install VMware Player or VirtualBox, and on the Mac, you can install Parallels or VMware Fusion. Using a VM offers you much more flexibility. You can install a desktop Linux distribution, like Ubuntu or Fedora. You can use this distribution to become familiar with basic Linux concepts, learn the command shell and learn how to build and run programs. You can reconfigure the kernel or load drivers, without the concern that you'll crash your desktop system. You can build the entire kernel and application environment, similar to what you might do with a cross-development environment for an Embedded Linux target.

If your VM running Linux crashes, you simply restart the VM. The crash doesn't affect other things which you might be doing on your development system, such as reading a web page on how to build and install a driver, or that writing an email to one of the many support mailing lists.

Some of the VM products have snapshot features that allow you to take a checkpoint of a known working configuration, to which you can roll back if you can't correct a crash easily. This snapshot is far easier than trying to rescue a crashing desktop system or an unresponsive target board.

A Linux VM running on your desktop is not a perfect model for an Embedded Linux environment. The VM emulates the hardware of a desktop system, with a limited set of devices that are unlikely to match a real embedded target. But our objective at this point is not modeling a real target (something we'll discuss later) but creating an environment were you can learn Linux concepts and programming easily.

This is the first step: Create a VM and install a desktop Linux distribution on the VM. We'll pick from here in our next installment.

Michael Eager is principal consultant at Eager Consulting in Palo Alto, Calif. He has over four decades experience developing compilers, debuggers, and simulators for a wide range of processor architectures used in embedded systems. His current and former clients include major semiconductor companies and systems developers. Michael has been a member of the ISO C++ Standard Committee and ABI Committees for several processor architectures. He is chair of the Debugging Standards Committee for DWARF, a widely used debug data format. He is active in the open-source and Linux communities.

Tuesday, September 10, 2013

Trusted Execution Technology (aka TXT): What is it?

Ref: http://communities.intel.com/community/vproexpert/blog/2011/01/25/trusted-execution-technology-aka-txt-what-is-it

In 2007, Intel introduced a new security feature on the business desktop line called Trusted Execution Technology (TXT). TXT was added to Intel vPro notebooks in 2008 and to the server platform in 2010. TXT is the foundation of a new generation of safe computers.

Many of the most sophisticated attacks against PC equipment nowadays aim to infect the user’s machines for different ends -- sending spam, DDoS attacks, information robbery. It has been a big challenge to mitigate them on the software layer.

As a hardware manufacturer, it’s our responsibility to join this battle and help the software industry develop more robust security solutions. However, Intel’s initiative isn’t the first one. Who remembers the ring hierarchy introduced on the 286 that allowed creating an operating system with privilege isolation? Or Execution Disable Bit, that helped prevent malware propagation on the machine, marking appropriated memory areas for code execution? We don’t treat security on just one layer and treating it in depth is not enough (e.g. software, hardware, and process). We must always be ahead of security issues, because it’s a race between who needs to be protected and who wants to attack.

Trusted Execution Technology (TXT) comes as a reinforcement to deal with threats that act on the same level of the kernel operating system or even more privileged levels -- like hypervisor’s malware, where the malicious code can take advantage of the CPU virtualization instructions to emulate hardware instructions and completely control the operating system.

How does it work?

Before we explain TXT, there is some groundwork to be done. First let’s understand how a key component in this technology works: the Trusted Platform Module, which is the root component of a secure platform. It’s a passive I/O device that is usually located at the LPC bus, and nowadays can be found as part of the North Bridge chipset. TPM has special registers, called PCR registers (i.e. PCR[0…23]) and can do some interesting things: Seal/Unseal secrets, allow Quoting (Remote Attestation) and do some crypto services, e.g. RSA, PRNG, etc.

The principle of TPM is that it is based on PCR extend operations, where it uses the previous PCR value to define the next one:

A single PCR can be extended multiple times and it’s computationally infeasible to define a specified value to a PCR, so the order where things happen matter [(ext(A),ext(B)) ≠ (ext(B),ext(A))] and the secret sealed in TPM can only be unsealed if the correct PCR values matches as presented in figure 1.

Figure 1 – Sealing/Unsealing TPM operation due PCR registers matching.

TPM is used also by Microsoft BitLocker, a full disk encryption technology, where the key to decrypt the disk is located in the TPM chip and the retrieving #_msocom_1 of this key depends on the integrity of the code that can be executed in memory, since the bootstrap and this process is known as Static Root Trust of Measurement (aka. SRTM) as presented in figure 2.

Figure 2 – Static Root Trust of Measurement

SRTM produces excellent results and a great level of security -- mainly against offline attacks --but the problem is that multiple components must be verified in the chain of trust once TPM is initialized. Verifying the integrity of each component in the path of computer initialization, as presented in figure 2, can become hard to manage due to the number of components involved. We need to measure every possible piece of code that might have been executed since the system boot; this imposes scalability issues.

Therefore, to cope with this limitation, TXT uses a different approach, named DRTM (Dynamic Root Trust of Measurement). Instead of validating every single piece of code, there is a magic new instruction called SENTER that has the capability to attest the integrity of the hypervisor loader or OS kernel code in a process known as Measure Launch. As presented in figure 3, the hypervisor loader issues the GETSEC[SENTER] instruction, which essentially performs a soft processor reset and loads a signedauthenticated code module (ACM), which can only be executed if it has a valid digital signature. This module verifies system configurations and BIOS elements by comparing against the “known good” values protected of sensitive memory areas by using Intel Virtualization Technology for Directed I/O (Intel VT-d) and chipset specific technologies, such as Intel Extended Page Tables (Intel EPT). Then it verifies and launches the host system (a hypervisor core or an OS kernel code), which configures low-level systems and protects itself using hardware assisted paging (HAP).

Figure 3 – Dynamic Root Trust of Measurement

TXT is the right technology for Measure Launch and, in conjunction with Intel Virtualization Technology (VT-x, VT-d and EPT), it’s also possible to implement run-time protection against malicious code.

Thursday, August 15, 2013

Execution address built-in functions for use in scatter files

Source: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0493c/CHDJDHFI.html

Execution address built-in functions for use in scatter files

The execution address related functions can only be used when specifying a base_address, +offsetvalue, or max_size. They map to combinations of the linker defined symbols shown in Table 4.

Table 4. Execution address related functions

Function	Linker defined symbol value
ImageBase(region_name)	Image$$region_name$$Base
ImageLength(region_name)	Image$$region_name$$Length + Image$$region_name$$ZI$$Length
ImageLimit(region_name)	Image$$region_name$$Base + Image$$region_name$$Length + Image$$region_name$$ZI$$Length

Function

Linker defined symbol value

ImageBase(region_name)

Image$$region_name$$Base

ImageLength(region_name)

Image$$region_name$$Length + Image$$region_name$$ZI$$Length

ImageLimit(region_name)

Image$$region_name$$Base + Image$$region_name$$Length + Image$$region_name$$ZI$$Length

The parameter region_name can be either a load or an execution region name. Forward references are not permitted. The region_name can only refer to load or execution regions that have already been defined.

Note

You cannot use these functions when using the .ANY selector pattern. This is because a .ANYregion uses the maximum size when assigning sections. The maximum size might not be available at that point, because the size of all regions is not known until after the .ANY assignment.

The following example shows how to use ImageLimit(region_name) to place one execution region immediately after another:

Example 10. Placing an execution region after another

LR1 0x8000
{
    ER1 0x100000
    {
        *(+RO)
    }
}
LR2 0x100000
{
    ER2 (ImageLimit(ER1))               ; Place ER2 after ER1 has finished
    {
        *(+RW +ZI)
    }
}

Using `+offset` with expressions

A +offset value for an execution region is defined in terms of the previous region. You can use this as an input to other expressions such as AlignExpr. For example:

LR1 0x4000
{
    ER1 AlignExpr(+0, 0x8000)
    {
        ...
    }
}

By using AlignExpr, the result of +0 is aligned to a 0x8000 boundary. This creates an execution region with a load address of 0x4000 but an execution address of 0x8000.

Thursday, June 6, 2013

Intel working on low-power Thunderbolt for tablets, smartphones

Intel says Thunderbolt on mobile devices depends on the future of WiGig, a wireless data transfer specification

By Agam Shah, IDG News Service
June 04, 2013 10:34 AM ET

Add a comment
Print

IDG News Service - A low-power Thunderbolt interconnect for smartphones and tablets is in the works, but the wired technology may not thrive if consumers prefer products using the wireless WiGig specification for data transfers.

There is a need for faster throughput so smartphones and tablets can connect to high-definition TVs and storage peripherals, said Dadi Perlmutter, executive vice president and general manager of the Intel Architecture Group, in an interview on the sidelines of the Computex trade show in Taipei.

[ IN THE NEWS: Asus, other PC makers announce laptops, desktops with Intel Haswell chips ]

The Thunderbolt data transfer technology shuttles data at high speeds between host computers and peripherals. Intel's mobile Thunderbolt interconnect will be a low-power version of its more power-hungry relative used in Macs and PCs, Perlmutter said. He did not provide a time frame on when the technology would be ready.

Apple was an early adopter of Thunderbolt, and if introduced, low-power Thunderbolt could be a candidate for use in iPhones and iPads. The mobile devices currently use the proprietary Lightning interconnect for charging and connecting to peripherals.

But in the end, adoption of Thunderbolt in smartphones and tablets depends on users, who may prefer wireless data transmission on mobile devices, Perlmutter said.

Intel is backing the WiGig specification, which can transfer data wirelessly at a rate of up to 7Gbps (bits per second), which is faster than standard Wi-Fi. WiGig operates over the 60GHz spectrum, and is intended for use over short distances or within a room. The Wireless Gigabit Alliance leads the development of the WiGig specification, and devices supporting the standard could go on sale next year. The Wi-Fi Alliance is eventually expected to take over WiGig development.

"Do users want Thunderbolt or do they want WiGig? They might want both. We are working on both," Perlmutter said.

"We'll see what's winning," Perlmutter said.

Most non-Apple smartphones and tablets today use the micro-USB ports to connect to peripherals, with USB 3.0 just reaching devices. Asustek introduced the Transformer Pad Infinity with a USB 3.0 port at Computex.

Also, adoption of Thunderbolt on desktops and laptops has been poor due to the dominance of USB 3.0, which is slower but ubiquitous. Thunderbolt peripherals and cables are also expensive relative to USB 3.0.

Intel in April doubled the speed of the Thunderbolt interconnect -- which supports the PCI-Express and DisplayPort protocols -- to 20Gbps. Standards-setting organizations PCI-Special Interest Group (PCI-SIG) and MIPI Alliance in February started work on a new M-PCIe (mobile PCI-Express) specification, which is due to be finalized this quarter.