It’s been a while since my previous blog, as I have been rather preoccupied with responding to a number of RFPs. However, I’ve managed to find some time to work on some demos for VxWorks MILS 2.1, which has been fun.
VxWorks MILS 2.1 introduced support for Wind River Linux as a Guest OS (VxWorks Guest OS and High Assurance Environment (HAE) having been supported in the earlier VxWorks MILS 2.0 release). I wanted to get some more hands-on experience of using Wind River Linux as a Guest OS (GOS) running on the VxWorks MILS 2.1 Separation Kernel (SK). So, I started with a version of the Blaster Blastee demo which had been modified by one of my colleagues in Engineering to use a Linux GOS partition for the Blaster. (Blaster Blastee is a well-known Wind River demo which provides a nice flexible framework for blasting TCP or UDP packets between nodes, testing network connectivity and performance).
I thought it would be an interesting exercise to extend the demo to also use Linux in a second partition as the Blastee (receiver), to demonstrate the scalability and determinism of the MILS SK with multiple Linux virtual boards (VB).
This proved to be quite easy to configure, as I was able to use the same Linux kernel image as the Blaster virtual board, but with different boot parameters (as this virtual board was using a separate dedicated Gigabit Ethernet device on my target board, with its own IP address), and I just invoked the Blastee executable which had been built into the Linux GOS filesystem. Once I had added a timeslot allocation for the Blastee VB into the MILS system schedule, I was able to build and run the system and send packets between the two partitions via external Gigabit Ethernet interfaces.
(Side note: Alternatively, I could have sent packets directly between the two partitions either by using Secure IPC ports via the MILS SK according to pre-defined security policy, or even via an IP tunnel over SIPC, but I used the external Ethernet interfaces, as I wanted to extend the demo further).
The next step was to configure this Linux GOS-based system to send and receive packets via the two Ethernet ports to corresponding VxWorks GOS-based Blaster and Blastee virtual boards on a second board. This configuration can be used to simulate a Public Network and a Secure Network connection between two nodes (see diagram above). The original MILS Blaster Blastee demo also includes a trusted Security Audit partition, running in a High Assurance Environment, which monitors the audit log for each partition, and also a Rogue partition which attempts to illegally access the Secure Network interface to intercept traffic (which is of course prevented by the MILS SK). When this demo is running freely, the link lights on my Gigabit switch flicker away furiously, and the VxWorks MILS partitions report output via the multiplexed serial I/O output to a host console.
To really see inside the system, and to step through the interactions of the sender and receiver (Linux Blaster to VxWorks Blastee over the Secure Network, and VxWorks Blaster to Linux Blastee on the Public Network), I used Wind River Workbench to debug all four connections concurrently, using Linux user-mode agents in each of the Linux VBs, and On-Chip Debugging (OCD) via JTAG to debug the VxWorks Blaster and Blastee. In this way, I could step through the sending and receiving of packets in both directions over the two networks (rather than having to rely on printf(), which would have been difficult to correlate across multiple partitions). The screen shot shows the point at which I am stepping through send and receive (the size of the screen shot is constrained by my 19” monitor).
So, this demo shows how the High Assurance Environment, VxWorks GOS and Linux GOS can all run on top of the MILS Separation Kernel and still provide good network performance despite being in a time-partitioned environment.
Subscribe
Comments