Blog Moved to Domain of One’s Own

At Brigham Young University we are experimenting with and piloting a Domain of One’s Own experience for students, faculty, staff, courses, and who knows what other uses we’ll find. To experience this environment I have chosen to move some of my content to my new blog at with the associated site being hosted by Reclaim Hosting.

The main focus of this experiment is to educate, encourage, and facilitate students in taking control of their digital identity. Instead of placing their content on social media sites where others drive how their content is displayed, what security policies exist, and how long their content persists, we are hoping to give students a place they can call their own and control the way their content is shared with others of their choosing.

However, we also hope to use this environment to implement a personal API for each of our participants. Imagine that when a domain is created and hosted, a subdomain is also created, perhaps api.domain. This URL points to an application implementing an API for the individual. This personal API would have resources pertaining to the individual that would be created, retrieved, updated or deleted using appropriate HTTP methods. These resources would be protected by Oauth, or some other mechanism, allowing the individual the ability to protect their information from others while authorizing those they desire to access it.

In the end, perhaps this sort of architecture will result in institutions, like BYU, not having to hold onto individual personal information, but rather asking students, staff, faculty and others for permission to access the needed information from the individual’s personal API. This would allow individuals to control the use and spread of their information and reduces the amount of personal information the institution needs to protect; as a CIO, I really like that last bit!

There are others working in this area including Kin LaneJim GroomPhil Windley, and others. If you want to participate, learn more, contribute or just listen in, please join us at the next University API and Domains (UAD) conference to be held again in early 2016.

Docker for Cross Compilation

Given my interests in enterprise computing and embedded systems, I decided to mix the two disciplines and use Docker to create a C development environment to generate Arm executable from my OS X based Mac. This may seem like a stretch, but the traditional way to do this is to fire up a full-blown virtual machine, install Linux, install the gcc based cross compiler, edit code on the host machine, switch to the VM, compile, and iterate.  This is slow and cumbersome, and not nearly as educational or fun!

The first step was to install boot2docker and follow the directions. This provided a simple and clean way to get Docker running on OS X.  Next I created a Dockerfile to create a Docker image FROM Ubuntu, loaded all the required modules and configured the image for cross compilation.  Here is my Dockerfile:

# This docker file creates an Arm cross compiler
# platform from Ubunto
# Ubunto as base image
FROM ubuntu
MAINTAINER J. Kelly Flanagan, Brigham Young University
# update ubuntu image
RUN apt-get update
# enable 32 bit code to run on 64 bit machine
RUN apt-get -y install lib32z1
# install the gcc tools to enable compilation
RUN apt-get -y install gcc build-essential libncurses5-dev mtd-utils u-boot-tools
# ADD cross compiler tools and unpack in appropriate location
# create destination directory
RUN mkdir /opt/codesourcery/
# ADD source
ADD arm* /opt/codesourcery/
ADD mkubifsimage /bin/
RUN chmod 777 /bin/mkubifsimage
# for interactive use set path
RUN echo ‘PATH=/opt/codesourcery/arm-2011.09/bin:$PATH’ >> /root/.bashrc
# set environment variable so I know I’m in a container
# create build directory where a volume will be mounted
RUN mkdir -p /tmp/arm_cross_compiler
# End Dockerfile

With this Dockerfile I ran the following build command using docker,

docker build -t ubuntu_arm_crosscompiler .

this resulted in a new Docker image called ubuntu_arm_crosscompiler. This image can be used to create an interactive Docker container by executing,

docker run -i -t ubuntu_arm_crosscompiler

This yields a shell where you can invoke gcc to create Arm object and executable files from source. However, I don’t use it interactively; I invoke it from make so that it appears as if I am compiling from my Mac, but end up with the desired Arm executable file.

As an example let’s assume we have a source directory with a Makefile and a few source files: Makefile, test.c, test.h, and testfunc.c.  The Makefile uses conditionals to determine whether it is executing on the host machine or the Docker container. In the Dockerfile the environment variable ARM_CROSS_COMPILER was set and will exist in any container derived from that image. The contents of the Makefile are included below.

# Name: Makefile
# Purpose: Build Arm executable via Docker based cross compiler
# Author: J. Kelly Flanagan
# Docker specific stuff
DOCKER_ARGS = -v $(PWD):/tmp/arm_cross_compiler -w /tmp/arm_cross_compiler
RM=rm -f
HEADERS = test.h
OBJECTS = test.o testfunc.o
TARGET = test
test: $(OBJECTS)
            $(CC) -o $@ $^ $(CFLAGS)
            @docker run $(DOCKER_ARGS) ubuntu_arm_crosscompiler make $@
%.o: %.c $(HEADERS)

            $(CC) -c -o $@ $

            @docker run $(DOCKER_ARGS) ubuntu_arm_crosscompiler make $@
            $(RM) $(OBJECTS) $(TARGET)

From the source directory we execute make and the first target (test) is invoked. This target invokes the next that checks to see if the header file or the source files are newer than the corresponding object files. If the object file doesn’t exist or the source file has been modified, the action is taken. The action checks to see if the ARM_CROSS_COMPILER environment variable is set. If it is not then the Docker command is executed. When the Docker container is created from the image it mounts the current working directory and executes the same make command that was invoked on the Mac. However, in the container the environment variable is set and the source file is compiled to an object file using the cross compiler. The make in the container now completes and returns to make on the Mac that then moves on to the next target. This is repeated until all object files have been created or updated at which point a final compilation takes place to link the object files to one executable.

Docker works well in this case because it is efficient enough to be invoked and destroyed quickly enough to not be a major contributor to compile time and it is much more convenient than switching back and forth between my host and a VM. Finally, I can share either the Dockerfile or the image with others, enabling them to easily use my tool chain. I’m definitely adding Docker to my standard set of tools for solving problems.

Criminals, Conjecture and Connected Things

My connected devices were initially secured using a hash-based message authentication code (HMAC).  An HMAC is constructed for each HTTP request directed at a device. The HMAC is created by combining some of the HTTP header elements, the time and date, the body of the request and a secret key / passwd.  The output block is then attached to the header of the request and transmitted to the selected device.  Upon reception of the request, the device collects the same header information, the time and date, and the body of the message and computes the HMAC using the same secret key / passwd.  If the computed HMAC and the one  sent with the request match, then the request is fulfilled.

While this protects the device from being compromised and the data being changed, it does nothing to protect the data from being read by prying eyes.  At first glance this seems unimportant since the data, inadvertently or intentionally, viewed by others carries little information.  For example, why would we care if others know the temperature of some sensor in our home? Why would it matter if someone knows the ringtone loaded in to our doorbell? Why would it matter if others know the setting on our thermostat?  Well each on their own might not matter, but with perhaps hundreds of devices in our home we offer up a lot of unprotected data for criminals to conjecture with.

Imagine a criminal mastermind sniffs your unprotected data and learns that your thermostat was just set to 55 degrees and the dog bark ringtone was loaded into your doorbell. In addition, late in the evening the temperature in the home is 55 degrees.  It wouldn’t be difficult to conjecture that no one is home.  In addition, the dog bark ringtone may lead them to believe that your gone for a while.

This simple example is intended to show that while we might erroneously think that this data does not need to be protected, it does!  In addition to protecting the device from intruders using HMAC, the data needs to be encrypted using SSL or other techniques.  By securing both, your connected devices and your data you will reduce the chance of having your virtual and physical spaces compromised by criminals.

Arduino As An AVR Debugger

When you leave the safety of the Arduino development environment and move to development with Atmel AVR processors, without an IDE, you lose some debugging / printing capabilities.  However, there is a simple technique to recover some functionality. This is not a replacement for real debugging tools, but rather a quick fix for simple print capability. I develop in an OS X environment with Emacs as my editor, avr-gcc as my compiler, and avrdude to download the compiled code to the AVR processor via an AVRISP mark II device.

Now the simple hack. You take an Arduino and make it a slave SPI device that simply reads data off of the SPI bus, when it is selected, and uses the Arduino’s Serial.print() capability to print the data over the USB port to the Arduino console. The following code performs this function.

You now setup the AVR microcontroller to be an SPI master and create print functions that meet your needs.  A simple function that prints a single byte or character is included below.  It simply selects the debug device, sends a byte of data over the SPI bus, and deselects the debug device.  When the Arduino receives the byte of data it is displayed on the Arduino console, our new debug window.

This function can now be used to create additional functions such as printStr(), etc.  As I said, a simple hack to solve a simple problem.

Domain of One’s Own @ BYU

At Brigham Young University we’ve noticed the work at Mary Washington University on the Domain of One’s Own.  I’ve been thinking for some time about providing each of our potential, matriculated and former students with a portfolio where they could deposit their application material before arriving, school work while here, and other contributions to society throughout their lives.

Students could then explicitly permit the institution to access and evaluate their work. They could permit potential employers to view samples of their work, and could interact with others through shared access, etc.

The  MWU Domain of One’s Own initiative may be a great start at such a tool. I love their concept that in addition to a tool to facilitate student learning it also teaches students to take control of their own data and to stake out their own digital identity. In addition to learning traditional college disciplines, they learn to interact and communicate in the virtual online world.

We’re going to learn from these pioneers and bring the knowledge to the students at BYU. This should be an interesting and fun experience.