Monday, December 29, 2014

Creating a custom Linux distribution for an ARM® Cortex®-A9 based SBC

The Yocto project provides an ideal platform for building a custom Linux distribution.  It's design was intended to model a machine.  The Yocto project or machine should take a number of inputs and produce an output.  The inputs to the machine are the specifications for the Linux distribution.  The output of the machine is the Linux distribution.

The Yocto project is the most widely supported system for building custom Linux distributions.
The Yocto project is very well supported by both communities and companies.  The project consists of a tool called bitbake and a build system that is based off of OpenEmbedded.  Together, these two components along with a defined set of metadata comprise what is called the Poky reference platform.

Tuesday, December 23, 2014

Setting up an ARM® Cortex®-A9 based SBC

The RiOTboard - an ARM® Cortex®-A9 based SBC

The RIoTboard is an ARM® Cortex®-A9 based single board computer (SBC).  The RIoTboard has a Freescale i.MX6 Solo application processor and an integrated Freescale Kinetis MCU for additional debugging and development.  The i.MX6 Solo supports the single ARM® Cortex®-A9 MPCore Platform.  The i.MX6 Solo contains ARM® TrustZone® technology and the i.MX 6 SoC on the RIoTboard has a 96 KB Boot Rom with support for high assurance boot.   Other features of the board include 1 GB of DDR3 memory, 4 GB eMMC, JTAG, Serial, mini USB for OpenSDA, mini USB for USB OTG, LVDS, parallel RGB expansion, 4 USB-A ports, HDMI, audio, reset button, microSD card slot, SD card slot, and boot onboard boot switches.   The board is very reasonably priced.  Last but not least, the Freescale i.MX 6 ARM® Cortex®-A9 application processor has ARM® TrustZone® technology.

ARM® TrustZone® Technology

The i.MX6 Solo processor on the RIoTboard is labeled MCIMX6S8DVM10AB.  According to the i.MX6 Solo data sheet, the processor supports a number of security related features. The list includes ARM® TrustZone® technology with TZ architecture support, a secure JTAG controller for locking down and protecting the JTAG port, a cryptographic acceleration and assurance module with secure RAM and a true PRNG, a central security unit (CSU) including secure non-volatile storage, high assurance boot, and the separation of memory and interrupts between secure world and normal world.  There are more security related features but this is a general list.

the view from above - a trusted zone

Monday, December 15, 2014

ARM®, NFC Technology, and the Single Wire Protocol

At the heart of an ARM Powered® smartphone with NFC technology is the contactless front end or CLF. The CLF is responsible for managing radio-frequency communication at 13.56 MHz.

A mobile phone with NFC technology contains only one CLF.  The CLF is connected to the ARM® processor or application processor via UART, I²C, and in some cases SPI.  These protocols are fairly basic and facilitate straightforward communication between the application processor and CLF via a typical Linux or UNIX-based kernel.  Updating the firmware on the CLF is a typical operation that is performed over the UART serial line.

While a mobile phone with NFC technology contains only one CLF, the phone may contain multiple secure elements. There may be a secure element on the UICC card, on the microSD card, and/or embedded with the CLF on the PCB.  Applets residing on each of the secure elements can serve both similar and different purposes.  Both the secure element and the CLF are small, self-contained computers with I/O communications interfaces. In the case where there are multiple secure elements residing on the phone, each of the secure elements is a small, self-contained computer with I/O communication interfaces.  A secure element differs from a normal computer in that it is embedded. It has limited resources available for performing computations.

Friday, December 12, 2014

ARM Powered® smartphones with NFC technology

Turing machines, first described by Alan Turing in (Turing 1937), are simple abstract computational devices intended to help investigate the extent and limitations of what can be computed.  - Stanford Encyclopedia of Philosophy
The head and the tape in a turing machine
There are a large number of Near field communication (NFC)-enabled phones (devices) on the consumer market. LG, Huawei, Motorola, Samsung, HTC, Nokia, ZTE, Sony, RIM, Amazon, and Apple manufacture and sell mobile phones with NFC technology.

Monday, December 8, 2014

The ARM® Cortex®-A9 Processor - Real World Uses

The ARM® Cortex®-A processor is found in compute-intensive applications.  ARM® Cortex®-A processors run full or rich operating systems such as Linux or UNIX.  I mentioned the ARM® Cortex®-A9 based MPCore in the last blog post.  The ARM® Cortex®-A9 processor processor is highly configurable.

ARM® Processor with Freescale logo (© Freescale Semiconductor)

Freescale Semiconductor implements an ARM® Cortex®-A9 processor called the i.MX 6.  Freescale sells the i.MX 6 processor in a lite, single, dual, dual-lite, and quad-core configuration. The i.MX 6 processor is used in critical applications across multiple industries.  These industries include aerospace, medical, and industrial.  i.MX processors can be found in Medical-CT scanners, ultrasound machines, automotive telematic systems, airplane computers, e-readers, and a host of other devices.  The power efficiency characteristics of the i.MX 6 make them attractive for wearables such as eye glasses and watches.

Sunday, December 7, 2014

ARM® TrustZone® technology - a Few Good Boards

ARM® provides a reference platform for software and hardware developers building systems based on ARM® Cortex®-A processors. The system is called the Juno ARM® Development Platform. The platform ships with a board that contains an ARM® Cortex®-A57 processor and ARM® Cortex®-A53 MPCore processor. The ARM® Cortex®-A57 processor and ARM® Cortex®-A57 processor are 64-bit and implement the ARM®v8-A instruction set architecture (ISA). A board support package can be built for this board using OpenEmbedded / Yocto.

You may notice that the Apple® A7 and Apple® A8 chips in the iPhone® 5c, iPhone® 5s, iPhone® 6, and iPhone® 6 Plus are based on the ARM® Cortex®-A53 and ARM® Cortex®-A57.  The Samsung Exynos 5433 Octa SoC also has an ARM® Cortex®-A57 and ARM® Cortex®-A53 MPCore.  The Samsung Galaxy Note 4 apparently has an 8-core Exynos 5433 processor in it.

Another development board is the Nvidia TK1 development board.  This board has a quad-core ARM® Cortex®-A15 processor.  These boards have been available for purchase at local retailers as of lately. However; the Nvidia K1 "Denver" is the latest product that they are working on and is not available for purchase yet.  It is rumored that the project "Denver" board has an ARM® Cortex®-A57 and an ARM® Cortex®-A53 MPCore.

The Freescale I.MX 6 processor has been hugely popular across a multitude of industries in a variety of embedded products. Freescale sells a development board with the I.MX 6 processor on it. The board is called the SABRE board for smart devices. The SABRE board has a Freescale I.MX 6 Quad Core ARM® Cortex®-A9 processor.   There are other vendors on the Internet that sell their variation of this development board.  One example is Boundary Devices. They sell their version of this board with the same Freescale I.MX 6 Quad Core ARM® Cortex®-A9 MPCore.  A board support package can be built for both the Freescale SABRE board and the Boundary Devices board using OpenEmbedded / Yocto.

There are a few key features of ARM development boards that should be taken into account if you purchase one. Namely; the e-fuses should not be blown out of the box. They should be left open. You can then blow the fuses to fit your configuration.

Here is a quick overview of the processors and boards I've mentioned above.

Dev Board
ARM® Cortex®-A57 and ARM® Cortex®-A53 MPCoreARM®ARM®v8-AJuno Ref PlatformYes
ARM® Cortex®-A15NvidiaARM®v7TK1Yes
ARM® Cortex®-A15SamsungARM®v7Arndale Exynos 5420Yes
ARM® Cortex®-A9 MPCoreFreescaleARM®v7Freescale SABREYes
ARM® Cortex®-A9 MPCoreFreescaleARM®v7Boundary DevicesYes
ARM® Cortex®-A9 MPCore + Zync 7000 FPGAXilinxARM®v7Zed BoardYes
ARM® Cortex®-A9 MPCore + Zync 7000 FPGAXilinxARM®v7Digilent ZyboYes

ARM and Cortex are registered trademarks of ARM Limited (or its subsidiaries) in the EU and/or elsewhere. All rights reserved. ARM and TrustZone are registered trademarks of ARM Limited (or its subsidiaries) in the EU and/or elsewhere. All rights reserved. ARM and SecurCore are registered trademarks of ARM Limited (or its subsidiaries) in the EU and/or elsewhere. All rights reserved. Freescale, the Freescale logo, AltiVec, C-5, CodeTEST, CodeWarrior, ColdFire, ColdFire+, C-Ware, the Energy Efficient Solutions logo, Kinetis, MagniV, mobileGT, PEG, PowerQUICC, Processor Expert, QorIQ, QorIQ Qonverge, Qorivva, Ready Play, SafeAssure, the SafeAssure logo, StarCore, Symphony, VortiQa, Vybrid and Xtrinsic are trademarks of Freescale Semiconductor, Inc., Reg. U.S. Pat. & Tm. Off. iPhone is a trademark of Apple Inc., registered in the U.S. and other countries

ARM® TrustZone® technology - from Monitor Mode to Dedicated Security Co-Processing and the Secure Element(s)

In the last blog post I explained how software running in normal world was different from software running in secure world. Each world, secure and normal, has an operating system and a set of applications that run on that operating system. The operating systems and application software are different between the two worlds.

I mentioned a key point in the last blog post: when you turn the power on to your phone, ARM®-Cortex®-based smartphones with ARM® TrustZone® technology allow two operating systems start up at the same time. The operating system in the secure world is called secure OS, and the operating system in the normal world is called normal OS. While both operating systems  run on the same physical processor, the secure OS typically has access to additional physical resources and hardware peripherals.

Saturday, December 6, 2014

ARM® TrustZone® technology - a Simple Example

Most of the consumer mobile phones on the market today are ARM Powered® products.
ARM Ltd. designs semiconductor IP blocks and then sells the license for the IP block to a semiconductor manufacturing company; i.e. Samsung, Apple, Nvidia, NXP, Freescale, etc. Some of these companies are fabless and some are not. ARM® TrustZone® technology is integrated into the ARM® Cortex®-A processor family. ARM® Cortex®-A-based microprocessors power many of today's smart phones.

The Smart Phone

Smart phones contain hardware components that enable them to communicate over computer networks to other people.  Bluetooth, cellular, and wi-fi are all examples of computer network technology.  For each of these types of networks, there is a dedicated piece of circuitry in the phone. For example, there is a bluetooth chip, there is a wi-fi chip, and there is a cellular modem chip. Sometimes these chips are combined into one, other times they are not.

Mobile phones also have hardware components such as cameras, speakers, microphones, and visual displays.  For each of these types of hardware components, there is a dedicated piece of circuitry in the phone.

Most people who have smart phones use their phone for taking pictures, playing music, and talking on the phone.  When the camera on the smart phone is used to take a picture, the camera application is opened.  Before the smart phone was purchased, the camera application was installed on the smart phone by the manufacturer.

When the camera button is clicked. the camera application talks to the operating system and the operating system talks to the camera circuitry and tells it to take a picture.  It is the operating system's responsibility to manage or mediate access to the camera circuitry.

When the dialer application is clicked on the phone, a phone number is typed and the call button is pressed.  The dialer application talks to the operating system and the operating system talks to the cellular modem, microphone, and speaker.

When the browser button is pressed on the phone, the browser application appears on the display. The browser application runs on top of the operating system.  The operating system is responsible for all of the system resources that the browser application uses. The operating system is also responsible for rendering the visual display on the screen of the smart phone so that when the browser button is clicked, the screen displays a window where the Web site address can be typed.

Keyboard Input

Lets say that you open the browser and visit your favorite retail site. You select an item for purchase and proceed to the checkout page. The checkout page then prompts you to enter your personal information and your credit card number.  A keyboard screen pops up and you begin to type in your credit card number.  At this point, it is important to remember the following.  You are typing in your credit card information inside of an application.  The application just happens to be the browser.  Continuing with the example, you proceed with typing in the additional information that is requested on the checkout page; the credit card expiration date, security code, zip code, and any other information requested. You then click the submit button and a message tells you that your payment has been accepted.

Drilling down one level into the detail, here is what is happening. Please note, this is intentionally very high-level.  I have left out all of technical jargon related to hardware interrupts, software interrupts, and operating system internals.  When you are typing information on the credit card payment page, each time that you press a letter or number on the keyboard, the hardware (touch display) tells the operating system that a character is available.  The operating system receives the character from the touch display hardware.  The operating system then takes the character and sends it to the application. This process repeats for every single character that you enter.  When you are done inputting the information, you hit the submit button, and your information is sent back to the operating system by the browser application.  The operating system packs your information up and then sends it to the network hardware.  This whole process involves copying your personal information between locations in physical memory on your phone; albeit, quite a few different memory locations.  This process also involves transferring your personal information over the circuitry in the phone.  You may ask, but wait, the browser says it uses HTTPS?  HTTPS secures the connection between your phone and the Web site where you are paying for your product.  The HTTPS protocol also attempts to provide a mechanism by which you can validate the authenticity of the Web site you are purchasing your product from.  But that is about it. It does not secure all of the important internals of memory-to-memory copies, application execution space, inter-process communication, and the storage of your personal information on the phone - should you choose to save this information on your phone.

Security 101

Operating systems such as Linux and FreeBSD (and its derivatives), and the embedded hardware that they reside on, are not designed for safely handling the input, storage, and transmission of credit card and personal information.  Additions have been made to these operating systems to make things more secure; but these additions are not and have not been sufficient.  The physical circuitry in and around the microprocessor is not secure.  The operating system software is not hardened or secured. The application software is not hardened or secured.  The keyboard input mechanism, which involves the hardware, the operating system, and the application, is not secured.   Various types of additions and enhancements have been made to make these things more secure, but they have not worked.  To fully secure an operating system and all of the application software that is running on it, is extremely expensive and is something that is not seen in the consumer market.

The entire keyboard input process which I described above in the paragraph about the credit card payment page is broken in terms of security.  There are physical vulnerabilities in the hardware circuitry - including but not limited to, the safe storage of your personal information in non-volatile storage, the transfer and copy of your personal information over the physical bus on the printed circuit board, and the transfer and storage of your personal information within volatile computer memory and last but least, the transfer of your personal information to and from the main processor on the printed circuit board in the phone.  In a nutshell, there are remote and local attack vectors, both at the hardware and software levels.  The attack vector space is not limited to keyboard input.  It involves everything that goes on in your phone.


ARM® TrustZone® technology is a system-wide approach to security.  So let's take the example where you were typing in your credit card and personal information into the browser application. The browser application and everything related to it all run on the operating system.  This includes the system level software frameworks for handling keyboard input, the system level code that is responsible for copying your personal information between memory locations in both the application's memory execution space and the operating system's memory space, ...the list goes on.

Here's what TrustZone can do.  Going back to the point in time where you open the browser application on the phone. After which, you type in the Web site address of the online store, and then click on the product that you are going to purchase, you are taken to the checkout page.  You then click on the little white box with a label above it that says
Credit Card Number - VISA/MasterCard/American Express

Upon clicking on that little white box below the label, a keyboard pops up. You click on the numerical key that corresponds to the first character in your credit card number. The touch display hardware notices that you pressed a key. Rather than sending that key to the operating system that manages the browser application, the touch display hardware sends that key to another operating system. Every key that you press while typing in your credit card number is handled by a different operating system and a different application. The browser application that you clicked on when you opened the browser, and the familiar items that you see on your phone when you turn the power on, cannot see your credit card number. A special operating system, this other operating system, and a special application are triggered when you click on the white box below the credit card payment label on the Web page.

This special operating system and special application run in a different world - sort of like a parallel universe. This special operating system and special application run in what is called secure world.
 The first example that I gave above, where I said the process is broken, well, that example highlights what happens when everything runs in normal world and secure world does not exist or is not being used if it does exist.  However; this new example where the special application running in the special world gathers your credit card information and then stores it somewhere, means that the ARM chip running in this phone has TrustZone support. What does this mean?  It means that there is a physically separate area inside of the processor that handles and stores your credit card information.  When its time to send your credit card information over the network, well, there is another special application inside of the special operating system that handles that.  The benefit?  Secure world has been physically secured on the printed circuit board and inside of the ARM chip.  By design, it is not susceptible to advanced light based attacks, timing attacks, x-ray analysis of the circuit, and the list goes on.  The memory space that the special application is executing inside of, within secure world, is physically and logically isolated.  The bus fabric that holds your personal information as it is transferred between hardware components, is isolated and secure.  All of this runs at the same time the browser application runs; its execution is interleaved in time - on very small time intervals.

In addition, everything going on in Secure World cannot be seen from normal world.  When you power on your phone, the operating system starts up in normal world. With TrustZone, the special operating system also starts up in parallel, within secure world.  As the operating system starts up in secure world, each piece of it is validated. This is important as it will be handling your personal information so we need to be sure that we know exactly where it came from, who developed it, their particular set of certifications, etc. etc.  This is known as a hardware initiated chain of trust.  As a consumer, I would like to know where and how the software that is running in secure world was validated.  The software running in normal world - my apps, and the stuff that came installed when I bought my phone, seems to work fine for now.  I don't think we will ever be able to validate the integrity of every single software component in normal world; however, if software running in secure world can be utilized to protect my personal information and credit card number, then by all means, the validation of that software should be straightforward.

Last but not least, software running in the secure world can access all of the hardware and all of the software that is running in the normal world. However; software running in the normal world cannot access software that is running in the secure world.

And finally, after you complete the input of your PIN number, your PIN number can be stored in a physically secure area of the chip that is protected by cryptographic keys.

This is one single, simple example of TrustZone.  There are variations and derivations. TrustZone encompasses different semiconductor IP blocks.  Just because a phone has an ARM processor with TrustZone, does not mean that a special operating system is running on TrustZone in secure world. As you can see, there are substantial benefits that can be gained from utilizing TrustZone and TEE for mobile payments.

So what does TrustZone accomplish?  These bullet points are straight from the ARM Web site
  • Secured PIN entry for enhanced user authentication in mobile payments & banking
  • Protection against trojans, phishing and APT (Advanced Persistent Threats)
  • Enable deployment and consumption of high-value media (DRM)
  • BYOD (Bring your own device) device persons and application separation
  • Software license management
  • Loyalty-based applications
  • Access control of cloud-based documents
  • e-Ticketing Mobile TV
This was a high-level overview of TrustZone and how its benefits can be realized in the context of keypad entry on a mobile phone.

ARM and Cortex are registered trademarks of ARM Limited (or its subsidiaries) in the EU and/or elsewhere. All rights reserved.  ARM and TrustZone are registered trademarks of ARM Limited (or its subsidiaries) in the EU and/or elsewhere. All rights reserved.  ARM and SecurCore are registered trademarks of ARM Limited (or its subsidiaries) in the EU and/or elsewhere. All rights reserved. Freescale, the Freescale logo, AltiVec, C-5, CodeTEST, CodeWarrior, ColdFire, ColdFire+, C-Ware, the Energy Efficient Solutions logo, Kinetis, MagniV, mobileGT, PEG, PowerQUICC, Processor Expert, QorIQ, QorIQ Qonverge, Qorivva, Ready Play, SafeAssure, the SafeAssure logo, StarCore, Symphony, VortiQa, Vybrid and Xtrinsic are trademarks of Freescale Semiconductor, Inc., Reg. U.S. Pat. & Tm. Off.

Thursday, December 4, 2014

ARM® TrustZone® technology

A large percentage of embedded devices contain ARM® technology.  The iPhone® and most of the Android phones contain an ARM® processor.  Netbooks, set-top boxes, VOIP phones, eReaders, tablets, home media players, internet routers, credit card point-of-sale (POS) terminals, medical lasers, heads-up displays (HUD), digital rights management, BYOD, industrial equipment, and numerous other types of embedded products contain ARM® processors.

ARM® licenses its semiconductor IP technology to most of the leading semiconductor manufacturing companies in the world.  This list of companies includes Freescale, NXP, Apple, Nvidia, Samsung, Qualcomm, ST, Atmel, and many others.  ARM® designs the microprocessor and then the licensee manufacturers the microprocessor.  There are numerous types of ARM® processors and each is suited for specific types of applications.

Microprocessors in the ARM® Cortex®-A processor family are designed for more compute-intensive operations.  Microprocessors in the ARM® Cortex®-A processor family contain different types of extensions.

ARM® TrustZone® architecture security extensions are designed to address system security as a whole.  ARM® Cortex®-A processors are designed with ARM® TrustZone® technology. 
ARM® TrustZone® technology is licensed as a series of semiconductor IP blocks. Its capabilities are extended outside of just the processor and into the entire system via specific IP blocks.

time-sliced execution -  context  switching
between secure world and normal world 
One of the notable features of ARM® TrustZone® technology is the ability of an ARM® TrustZone® microprocessor to allow software to execute in parallel worlds.  For instance, software running in a secure mode of execution on your phone can handle sensitive information such as credit card pin number input.

The Linux community has embraced ARM® technology and the Linux kernel has been ported across numerous variations of the ARM®microprocessor.

Some of the more widely used consumer products have ARM® microprocessors with ARM® TrustZone extensions; these include the iPhone, Samsung Series of Phones, LG, and many of the other Android-based phones.

note: Intel has technology similar to TrustZone

ARM and Cortex are registered trademarks of ARM Limited (or its subsidiaries) in the EU and/or elsewhere. All rights reserved.  ARM and TrustZone are registered trademarks of ARM Limited (or its subsidiaries) in the EU and/or elsewhere. All rights reserved.  ARM and SecurCore are registered trademarks of ARM Limited (or its subsidiaries) in the EU and/or elsewhere. All rights reserved. Freescale, the Freescale logo, AltiVec, C-5, CodeTEST, CodeWarrior, ColdFire, ColdFire+, C-Ware, the Energy Efficient Solutions logo, Kinetis, MagniV, mobileGT, PEG, PowerQUICC, Processor Expert, QorIQ, QorIQ Qonverge, Qorivva, Ready Play, SafeAssure, the SafeAssure logo, StarCore, Symphony, VortiQa, Vybrid and Xtrinsic are trademarks of Freescale Semiconductor, Inc., Reg. U.S. Pat. & Tm. Off.

Monday, November 24, 2014

crypto keys, cold storage, etc...

Stainless Steel Fermentation Tanks at a popular winery in Northern California - Nikon D80
In the room where I took this photograph, the ambient light reflects off of the stainless steel vats creating a specular highlight known as an anisotropic reflection.

 Cold storage in the context of Internet jargon refers to the storage of cryptographic keys (private key) on some type of physical medium that is not connected to the Internet and is not susceptible to external electric fields.  A Faraday cage placed below the surface of the ground could be a choice.  Since cryptographic keys can be copied, the keys are stored at multiple geographic locations for redundancy in case of natural disaster.

For an explanation of private keys, key parirs, and symmetric vs asymmetric systems, please see my paper on Public Key Cryptography.

Friday, November 21, 2014

C++ - Generative Programming

Nikon D80 - Alcatraz from Twin Peaks
San Francisco Bay Area from Twin Peaks - Nikon D80

C++ IOStreams are a powerful mechanism for transforming input into output.  Most programmers are at least familiar with C++ IOStreams in the context of reading and writing bytes to a terminal or file.

When a file or terminal is opened for reading or writing by a process, the operating system returns a numerical identifier to the process.  This numerical identifier is known as a file descriptor.
In turn, the file or terminal can be written to by the process via this file descriptor.  The read and write system calls, which are implemented as wrappers in libc, are passed this numerical file descriptor.

Many layers of abstraction reside on top of the read and write system calls.  These layers of abstraction are implemented in both C and C++. Examples of C based layers of abstraction are fprintf and printf. Internally, these functions call the write system call.   An example of a C++ based layer of abstraction is the IOStreams hierarchy.  Out of the box, most C++ compiler toolchains provide an implementation of IOStreams.  IOStreams are an abstraction on top of the read and write system calls. When data is written to a terminal via an IOStream, the IOStream implementation calls the write system call.  Lastly, these layers of abstraction handle things such as buffering and file synchronization.

In UNIX, everything is a file. Consequently, network devices, virtual terminals, files, block devices, etc. can all be written to via a numerical file descriptor - this in turn is why UNIX is referred to as having a uniform descriptor space. With this being said, the basic IOStreams and printf abstractions I mentioned above are not designed to used with network sockets, pipes, and the sort.  The lower layer read and write system calls can be used but there are a number of functions that must be called before writing raw bytes to an open file descriptor that points to a network socket.

The additional functionality that is needed for communicating with network sockets, shared memory, and the like, can be implemented in classes that are derived from the C++ iostream class.  It is for this reason that the IOStreams classes are extended via inheritance.

Over the years, several popular C++ libraries have implemented classes that are derived from the base classes in the iostreams hierarchy.  The C++ Boost library is a popular example.  However; this has not always been the case.  Going back to 1999, the Boost library did not exist and there were one or two examples on the entire Internet as to how to properly extend the C++ IOStreams classes.  

In 1999, I pulled the source code for the GNU compiler toolchain that is available on and derived a class hierarchy to support sockets, pipes, and shared memory. The methods in the classes that I derived from the base classes in the iostreams library were designed to be reentrant and easy to use.  I used generative programming techniques and template metaprogramming to create objects that could be instantiated using familiar C++ iostreams syntax and semantics. The library that I created is called mls and it is licensed under version 2 of the GPL.  MLS is available on github.

Since 1999, Boost has come a long way.  It provides support for cryptographic IOStreams, sockets, and all kinds of other fancy stuff. It uses generative programming techniques. It is very clean and I highly recommend it.

If you would prefer to roll your own, then I would suggest downloading the gnu compiler toolchain source code from  From there, you can run ctags over the source tree and begin to dig into the internals of the iostreams hierarchy. I would also recommend the following book 
Generative Programming - Methods, Tools, and Applications.  Last but not least, you'll need a Linux host with a reasonable distribution running on it, such as Fedora.

namespace mls 
  template<class BufType, int direction, class BaseType=mlbuf> class mlstreamimpl;
  template<class Parent, class BaseType=mlbuf> class mloutputimpl;
  template<class Parent, class BaseType=mlbuf> class mlinputimpl;
  template<class BufType, int direction, class BaseType=BufType>
  struct StreamConfig;
  template<class BufType, int direction, class BaseType>
  struct StreamConfig
    typedef typename SWITCH<(direction),
    CASE<0,mlinputimpl<mlstreamimpl<BufType, direction, BaseType>, BufType>,
    CASE<1,mloutputimpl<mlstreamimpl<BufType, direction, BaseType>, BufType>,
    CASE<10,mlinputimpl<mloutputimpl<mlstreamimpl<BufType, direction, BaseType>, 
         BufType>, BufType >,
    CASE<DEFAULT,mlinputimpl<mlstreamimpl<BufType, 10, BaseType>, 
         BufType > > > > > >::RET Base;