Stephen Smith's Blog

Musings on Machine Learning…

Archive for the ‘raspberry pi’ Category

Erlang on the Raspberry Pi

leave a comment »

Introduction

Erlang is a rather interesting programming language with a number of rather unique properties. If you are used to procedural languages like C or its many variants, then Erlang will appear very different. Erlang was originally developed by Ericsson to program telephone switches. The name is either based on Ericsson Language or is named after Agner Krarup Erlang depending on who you ask. In Erlang there are no loops, all loops are accomplished via recursion. Similarly once a variable is assigned, it can never be changed (is immutable). A lot of the function execution is controlled via pattern matching. Beyond the basic language the Erlang system is used to create highly available, scalable fault tolerant systems. You can even swap code on the fly without stopping the system. Erlang is still used in many telephony type applications, but it is also used to create highly reliable and scalable web sites. The best known being WhatsApp. Plus Facebook, Yahoo and many others have services implemented in Erlang serving massive numbers of users.

In this article we’ll begin to look at the basic language and consider an implementation of our flashing LED program for the Raspberry Pi implemented in pure Erlang. ERLang runs on most operating systems and is open source now. It is easy to add to the Raspberry Pi and is a very good system if you want to make use of a cluster of Raspberry Pis.

How to Run the Program

Erlang doesn’t come pre-installed with Raspbian, but it’s easy to add with the command:

sudo apt-get install erlang

After this completes you are good to go.

Erlang includes a terminal based command system where you can compile modules and call functions. To run the programs included here, you need to save the first file as lights.erl and the second as gpio.erl. Then you can compile and execute the program as indicated in the screenshot of my terminal window below:

Some things to note:

  1. Erlang is case sensitive and case has meaning. For instance variables start with a capital letter and functions with a lowercase letter.
  2. Punctuation is very important. The periods end a statement and in the erl shell will cause it to execute. If you miss the period, nothing will happen until you enter one (it assumes you have more text to enter). Similarly inside functions , and ; have a specific meaning that affects how things run.
  3. You do everything by calling functions both in the shell and in the Erlang language. So the c() function compiles a module (produces a .beam file). The q() function exits the shell after terminating all programs. lights:flashinglights() is our exported entry point function to run the program with. You can also call things like ls() to get a directory listing or cd() to change directories or pwd() to find out where you are. Remember to enter any lines with a period to terminate the line.
  4. To access the gpio /sys files, erl must be run from sudo. You could fix the file system permissions, but this seems easy enough.

Flashing LED Program

Below is my main module to flash the lights. Unlike the C or Fortran version of this program, there is no loop, since loops don’t exist in Erlang. Instead it uses recursion to accomplish the same things. (Actually in the Erlang tutorials there are design patterns on how to accomplish while or for loops with recursion). Notice that once a variable is assigned it can never be changed. But you accomplish the same thing with recursion by passing a modified version of the variable into a function. Similarly you can preserve variables using function closures, but I don’t do that here. I included edoc comments which are Erlang version of JavaDoc. Otherwise this is just intended to give a flavour for the language without going into too much detail.

 

%% @author Stephen Smith
%% @copyright 2018 Stephen Smith
%% @version 1.0.0
%% @doc
%% A erlang implementation of my flashing lights program
%% for the Raspberry Pi.
%% @end

-module(lights).
-export([flashlights/0]).
-author('Stephen Smith').

flashlights() ->
    Leds = init(),
    flash(Leds, 10).

init() ->
    L0 = gpio:init(17, out),
    L1 = gpio:init(27, out),
    L2 = gpio:init(22, out),
    {L0, L1, L2}.

flash(Leds, Times) when Times > 0 ->
    gpio:write(element(1, Leds), 1),
    timer:sleep(200),
    gpio:write(element(1, Leds), 0),
    gpio:write(element(2, Leds), 1),
    timer:sleep(200),
    gpio:write(element(2, Leds), 0),
    gpio:write(element(3, Leds), 1),
    timer:sleep(200),
    gpio:write(element(3, Leds), 0),

    flash(Leds, Times-1);

flash(Leds, Times) when Times =< 0 ->
    true.

Erlang GPIO Library

Rather than write the file access library for the GPIO drivers myself, doing a quick Google search revealed several existing ones including this one from Paolo Oliveira.

 

%% @author Paolo Oliveira <paolo@fisica.ufc.br>
%% @copyright 2015-2016 Paolo Oliveira (license MIT)
%% @version 1.0.0
%% @doc
%% A simple, pure erlang implementation of a module for 
%% <b>Raspberry Pi's General Purpose
%% Input/Output</b> (GPIO), using the standard Linux kernel
%% interface for user-space, sysfs,
%% available at <b>/sys/class/gpio/</b>.
%% @end

-module(gpio).
-export([init/1, init/2, handler/2, read/1, write/2, stop/1]).
-author('Paolo Oliveira <paolo@fisica.ufc.br>').

%% API

% @doc: Initialize a Pin as input or output.
init(Pin, Direction) ->
  Ref = configure(Pin, Direction),
  Pid = spawn(?MODULE, handler, [Ref, Pin]),
  Pid.

% @doc: A shortcut to initialize a Pin as output.
init(Pin) ->
  init(Pin, out).

% @doc: Stop using and release the Pin referenced as file descriptor Ref.
stop(Ref) ->
  Ref ! stop,
  ok.

% @doc: Read from an initialized Pin referenced as the file descriptor Ref.
read(Ref) ->
  Ref ! {recv, self()},
  receive
    Msg ->
      Msg
  end.

% @doc: Write value Val to an initialized Pin referenced as the file descriptor Ref.
write(Ref, Val) ->
  Ref ! {send, Val},
  ok.

%% Internals

configure(Pin, Direction) ->
  DirectionFile = "/sys/class/gpio/gpio" ++ integer_to_list(Pin) ++ "/direction",

  % Export the GPIO pin
  {ok, RefExport} = file:open("/sys/class/gpio/export", [write]),
  file:write(RefExport, integer_to_list(Pin)),
  file:close(RefExport),

  % It can take a moment for the GPIO pin file to be created.
  case filelib:is_file(DirectionFile) of
      true -> ok;
      false -> receive after 1000 -> ok end
  end,

  {ok, RefDirection} = file:open(DirectionFile, [write]),
  case Direction of
    in -> file:write(RefDirection, "in");
    out -> file:write(RefDirection, "out")
  end,
  file:close(RefDirection),
  {ok, RefVal} = file:open("/sys/class/gpio/gpio" ++ integer_to_list(Pin) ++ "/value", [read, write]),
  RefVal.

release(Pin) ->
  {ok, RefUnexport} = file:open("/sys/class/gpio/unexport", [write]),
  file:write(RefUnexport, integer_to_list(Pin)),
  file:close(RefUnexport).

% @doc: Message passing interface, should not be used directly, it is present for debugging purpose.
handler(Ref, Pin) ->
  receive
    {send, Val} ->
      file:position(Ref, 0),
      file:write(Ref, integer_to_list(Val)),
      handler(Ref, Pin);
    {recv, From} ->
      file:position(Ref, 0),
      {ok, Data} = file:read(Ref, 1),
      From ! Data,
      handler(Ref, Pin);
    stop ->
      file:close(Ref),
      release(Pin),
      ok
   end.

%% End of Module.

Summary

Erlang is a very interesting language. If you are interested in functional programming or how to create highly scalable reliable web servers, then Erlang is definitely worth checking out. We only looked at a quick introduction to the language, really by example. There are lots of good documentation, tutorials and samples just a Google search away. Perhaps in a future article we’ll look at processes and messages and how to build such a highly scalable server.

 

Advertisements

Written by smist08

February 18, 2018 at 11:59 pm

Posted in raspberry pi

Tagged with , ,

Kali Linux on the Raspberry Pi

leave a comment »

Introduction

Raspbian is the main operating system for the Raspberry Pi, but there are quite a few alternatives. Raspbian is based on Debian Linux and there has been a good uptake on the Raspberry Pi which means that most Linux applications have ARM compiled packages available through the Debian APT package manager. As a consequence it’s quite easy to create a Raspberry Pi Linux distribution, so there are quite a few of them. Kali Linux is a specialist distribution that is oriented to hackers (both black and white hat). It comes with a large number of hacking tools for gaining access to networks, compromising computers, spying on communications and other fun things. One cool thing is that Kali Linux has a stripped down version for the Raspberry Pi that is oriented towards a number of specialized purposes. However with the apt-get package manager you can add pretty well anything that has been left out.

If you watch the TV show Mr. Robot (highly recommended) then you might notice that all the cool in-the-know people are running Kali Linux. If you want to get a taste of what it’s all about and you have a Raspberry Pi then all you need is a free micro-SD card to give it a try.

Are You a Black or White Hat?

If you are a black hat hacker looking to infiltrate or damage another computer system, then you probably aren’t reading this blog. Instead you are somewhere on the darknet reading much more malicious articles than this one. This article is oriented more to white hat hackers or to system administrators looking to secure their computing resources. The reason it’s important for system administrators to know about this stuff is that they need to know what they are really protecting against. Hackers are very clever and are always coming up with new hacks and techniques. So it’s important for the good guys to know a bit about how hackers think and to have defenses and protections against the imaginative attacks that might come their way. This now includes the things the bad guys might try to do with a Raspberry Pi.

Anyone that is responsible for securing a network or computer has to test their security and certainly one easy way to get started is to hit it with all the exploit tools included with Kali Linux.

Why Kali on the Pi?

A lot of hacking tasks like cracking WiFi passwords take a lot of processing power. Cracking WPA2 passwords is usually done on very powerful computers with multiple GPU cards and very large dictionary databases. Accomplishing this on a Raspberry Pi would pretty much take forever if it could actually do it. Many hacking tasks are of this nature, very compute intensive.

The Raspberry Pi is useful due to its low cost and small size. The low cost makes it disposable, if you lose it then it doesn’t matter so much and the small size means you can hide it easily. So for instance one use would be to hide a Raspberry Pi at the site you are trying to hack. Then the Raspberry Pi can monitor the Wifi traffic looking for useful data packets that can give away information. Or even leave the Pi somewhere hidden connected to a hardwired ethernet connection. Then Kali Linux has tools to get this information to external sources in a secretive way and allows you to remotely control it to direct various attacks.

Many companies build their security like eggs with a hard to penetrate shell and often locating a device on their premises can bypass their main security protections. You can then run repeated metasploit attacks looking for weaknesses from the inside. Remember your security should be more like an onion with multiple nested layers, so getting through one doesn’t give an attacker access to everything.

Installing Kali Linux

The Kali Linux web site includes a complete disk image of the Raspberry Pi version. You just need to burn this to a micro-SD card using a tool like ApplePi Baker. They you just put the micro-SD in your Raspberry Pi, turn it on and off you go. However there are a few necessary steps to take before you really start:

  1. The root password is toor, so change this first time you boot up.
  2. The Kali Linux instructions point out you need to refresh your SSH certificates since otherwise you get the ones included with the image. The download page has instructions on how to do this.
  3. The image is configured for 8Gig so if you have a larger SD card then you need to repartition it to get all the free space. I used the GParted program for this which I got via “apt-get install gparted”. Note that to use apt-get you need to connect to WiFi or the Internet. Another option is to get Raspbian’s configuration program and use that, it works with most variants of Debian Linux and allows you to do some other things like setup overclocking. You can Google for the wget command to get this.
  4. Update the various installed programs via “apt-get update” and “apt-get upgrade”. (If you aren’t still logged on as root you need to sudo these).

Now you are pretty much ready to play. Notice that you are in a nice graphical environment and that the application menu is full of hacking tools. These aren’t as many hacking tools as the full Kali distribution, but these are all ones that work well on the Raspberry Pi. They als limited the number so you can run off a really cheap 8 Gig micro-SD card.

I see people say you should stick to command line versions of the tools on the Pi due to its processing power and limited memory, but I found I could add the GUI versions and these worked fine. For instance the nmap tool is installed, but the zenmap graphical front end isn’t. Adding zenmap is easy via “apt-get install zenmap” and then this seems to work fine. I think the assumption is that most people will use the Raspberry version of Kali headless (meaning no screen or keyboard) so it needs to be accessed via remote control software like secure shell which means you want to avoid GUIs.

Summary

Installing Kali Linux on a micro-SD card for your Raspberry Pi si a great way to learn about the various tools that hackers can easily use to try and penetrate, spy on or interfere with people’s computers. There are quite a few books on this as well as many great resources on the Web. Kali’s website is a great starting point. Anyway I find it quite eye opening the variety of readily tools and how easy it is for anyone to use them.

Written by smist08

January 16, 2018 at 3:01 am

Flashing LEDs in Assembler

leave a comment »

Introduction

Previously I wrote an article on an introduction to Assembler programming on the Raspberry Pi. This was quite a long article without much of a coding example, so I wanted to produce an Assembler  language version of the little program I did in Python, Scratch, Fortran and C to flash three LEDs attached to the Raspberry Pi’s GPIO port on a breadboard. So in this article I’ll introduce that program.

This program is fairly minimal. It doesn’t do any error checking, but it does work. I don’t use any external libraries, and only make calls to Linux (Raspbian) via software interrupts (SVC 0). I implemented a minimal GPIO library using Assembler Macros along with the necessary file I/O and sleep Linux system calls. There probably aren’t enough comments in the code, but at this point it is fairly small and the macros help to modularize and explain things.

Main Program

Here is the main program, that probably doesn’t look structurally that different than the C code, since the macro names roughly match up to those in the GPIO library the C function called. The main bit of Assembler code here is to do the loop through flashing the lights 10 times. This is pretty straight forward, just load 10 into register r6 and then decrement it until it hits zero.

 

@
@ Assembler program to flash three LEDs connected to the
@ Raspberry Pi GPIO port.
@
@ r6 - loop variable to flash lights 10 times
@

.include "gpiomacros.s"

.global _start             @ Provide program starting address to linker

_start: GPIOExport  pin17
        GPIOExport  pin27
        GPIOExport  pin22

        nanoSleep

        GPIODirectionOut pin17
        GPIODirectionOut pin27
        GPIODirectionOut pin22

        @ setup a loop counter for 10 iterations
        mov         r6, #10

loop:   GPIOWrite   pin17, high
        nanoSleep
        GPIOWrite   pin17, low
        GPIOWrite   pin27, high
        nanoSleep
        GPIOWrite   pin27, low
        GPIOWrite   pin22, high
        nanoSleep
        GPIOWrite   pin22, low

        @decrement loop counter and see if we loop
        subs    r6, #1      @ Subtract 1 from loop register setting status register
        bne     loop        @ If we haven't counted down to 0 then loop

_end:   mov     R0, #0      @ Use 0 return code
        lsl     R0, #2      @ Shift R0 left by 2 bits (ie multiply by 4)
        mov     R7, #1      @ Service command code 1 terminates this program
        svc     0           @ Linus command to terminate program

pin17:      .asciz  "17"
pin27:      .asciz  "27"
pin22:      .asciz  "22"
low:        .asciz  "0"
high:       .asciz  "1"

 

GPIO and Linux Macros

Now the real guts of the program are in the Assembler macros. Again it isn’t too bad. We use the Linux service calls to open, write, flush and close the GPIO device files in /sys/class/gpio. Similarly nanosleep is also a Linux service call for a high resolution timer. Note that ARM doesn’t have memory to memory or operations on memory type instructions, so to do anything we need to load it into a register, process it and write it back out. Hence to copy the pin number to the file name we load the two pin characters and store them to the file name memory area. Hard coding the offset for this as 20 isn’t great, we could have used a .equ directive, or better yet implemented a string scan, but for quick and dirty this is fine. Similarly we only implemented the parameters we really needed and ignored anything else. We’ll leave it as an exercise to the reader to flush these out more. Note that when we copy the first byte of the pin number, we include a #1 on the end of the ldrb and strb instructions, this will do a post increment by one on the index register that holds the memory location. This means the ARM is really very efficient in accessing arrays (even without using Neon) we combine the array read/write with the index increment all in one instruction.

If you are wondering how you find the Linux service calls, you look in /usr/include/arm-linux-gnueabihf/asm/unistd.h. This C include file has all the function numbers for the Linux system calls. Then you Google the call for its parameters and they go in order in registers r0, r1, …, r6, with the return code coming back in r0.

 

@ Various macros to access the GPIO pins
@ on the Raspberry Pi.

@ R5 is used for the file descriptor

.macro  openFile    fileName
        ldr         r0, =\fileName
        mov         r1, #01     @ O_WRONLY
        mov r7,     #5          @ 5 is system call number for open
        svc         0
.endm

.macro  writeFile   buffer, length
        mov         r0, r5      @ file descriptor
        ldr         r1, =\buffer
        mov         r2, #\length
        mov         r7, #4 @ 4 is write
        svc         0
.endm

.macro  flushClose
@fsync syscall
        mov         r0, r5
        mov         r7, #118    @ 118 is flush
        svc         0

@close syscall
        mov         r0, r5
        mov         r7, #6      @ 6 is close
        svc         0
.endm

@ Macro nanoSleep to sleep .1 second
@ Calls Linux nanosleep entry point which is function 162.
@ Pass a reference to a timespec in both r0 and r1
@ First is input time to sleep in seconds and nanoseconds.
@ Second is time left to sleep if interrupted (which we ignore)

.macro  nanoSleep
        ldr         r0, =timespecsec
        ldr         r1, =timespecsec
        mov         r7, #162    @ 162 is nanosleep
        svc         0
.endm

.macro  GPIOExport  pin
        openFile    gpioexp
        mov         r5, r0      @ save the file descriptor
        writeFile   \pin, 2
        flushClose
.endm

.macro  GPIODirectionOut   pin
        @ copy pin into filename pattern
        ldr         r1, =\pin
        ldr         r2, =gpiopinfile
        add         r2, #20
        ldrb        r3, [r1], #1 @ load pin and post increment
        strb        r3, [r2], #1 @ store to filename and post increment
        ldrb        r3, [r1]
        strb        r3, [r2]
        openFile    gpiopinfile
        writeFile   outstr, 3
        flushClose
.endm

.macro  GPIOWrite   pin, value
        @ copy pin into filename pattern
        ldr         r1, =\pin
        ldr         r2, =gpiovaluefile
        add         r2, #20
        ldrb        r3, [r1], #1    @ load pin and post increment
        strb        r3, [r2], #1    @ store to filename and post increment
        ldrb        r3, [r1]
        strb        r3, [r2]
        openFile    gpiovaluefile
        writeFile   \value, 1
        flushClose
.endm

.data
timespecsec:   .word   0
timespecnano:  .word   100000000
gpioexp:    .asciz  "/sys/class/gpio/export"
gpiopinfile: .asciz "/sys/class/gpio/gpioxx/direction"
gpiovaluefile: .asciz "/sys/class/gpio/gpioxx/value"
outstr:     .asciz  "out"
            .align  2          @ save users of this file having to do this.
.text

Makefile

Here is a simple makefile for the project if you name the files as indicated. Again note that WordPress and Google Docs may mess up white space and quote characters so these might need to be fixed if you copy/paste.

model: model.o
    ld -o model model.o

model.o: model.s gpiomacros.s
    as -ggdb3 -o model.o model.s

clean:
    rm model model.o

 

IDE or Not to IDE

People often do Assembler language development in an IDE like Code::Blocks. Code::Blocks doesn’t support Assembler language projects, but you can add Assembler language files to C projects. This is a pretty common way to do development since you want to do more programming in a higher level language like C. This way you also get full use of the C runtime. I didn’t do this, I just used a text editor, make and gdb (command line). This way the above program has no extra overhead the executable is quite small since there is no C runtime or any other library linked to it. The debug version of the executable is only 2904 bytes long and non debug is 2376 bytes. Of course if I really wanted to reduce executable size, I could have used function calls rather than Assembler macros as the macros duplicate the code everywhere they are used.

Summary

Assembler language programming is kind of fun. But I don’t think I would want to do too large a project this way. Hats off to the early personal computer programmers who wrote spreadsheet programs, word processors and games entirely in Assembler. Certainly writing a few Assembler programs gives you a really good understanding of how the underlying computer hardware works and what sort of things your computer can do really efficiently. You could even consider adding compiler optimizations for your processor to GCC, after all compiler code generation has a huge effect on your computer’s performance.

Written by smist08

January 7, 2018 at 7:08 pm

Spectre Attacks on ARM Devices

leave a comment »

Introduction

I predicted that 2018 would be a very bad year for data breaches and security problems, and we have already started the year with the Intel x86 specific Meltdown exploit and the Spectre exploit that works on all sorts of processors and even on some JavaScript systems (like Chrome). Since my last article was on Assembler programming and most of these type exploits are created in Assembler, I thought it might be fun to look at how Spectre works and get a feel for how hackers can retrieve useful data out of what seems like nowhere. Spectre is actually a large new family of exploits so patching them all is going to take quite a bit of time, and like the older buffer overrun exploits, are going to keep reappearing.

I’ve been writing quite a bit about the Raspberry Pi recently, so is the Raspberry Pi affected by Spectre? After all it affects all Android and Apple devices based on ARM processors. The main Raspberry Pi operating system is Raspbian which is variant of Debian Linux optimized for the Pi. A recent criticism of Raspbian is that it is still 32-Bit. It turns out that running the ARM in 32-bit mode eliminates a lot of the Spectre attack scenarios. We’ll discuss why this is in the article. If you are running 64-Bit software on the Pi (like running Android) then you are susceptible. You are also susceptible to the software versions of this attack like those in JavaScript interpreters that support branch prediction (like Chromium).

The Spectre hacks work by exploiting how processor branch prediction works coupled with how data is cached. The exploits use branch prediction to access data it shouldn’t and then use the processor cache to retrieve the data for use. The original article by the security researchers is really quite good and worth a read. Its available here. It has an appendix at the back with C code for Intel processors that is quite interesting.

Branch Prediction

In our last blog post we mentioned that all the data processing assembler instructions were conditionally executed. This was because if you perform a branch instruction then the instruction pipeline needs to be cleared and restarted. This will really stall the processor. The ARM 32-bit solution was good as long as compilers are good at generating code that efficiently utilize these. Remember that most code for ARM processors is compiled using GCC and GCC is a general purpose compiler that works on all sorts of processors and its optimizations tend to be general purpose rather than processor specific. When ARM evaluated adding 64-Bit instructions, they wanted to keep the instructions 32-Bit in length, but they wanted to add a bunch of instructions as well (like integer divide), so they made the decision to eliminate the bits used for conditionally executing instructions and have a bigger opcode instead (and hence lots more instructions). I think they also considered that their conditional instructions weren’t being used as much as they should be and weren’t earning their keep. Plus they now had more transistors to play with so they could do a couple of other things instead. One is that they lengthed the instruction pipeline to be much longer than the current three instructions and the other was to implement branch prediction. Here the processor had a table of 128 branches and the route they took last time through. The processor would then execute the most commonly chosen branch assuming that once the conditional was figured out, it would very rarely need to throw away the work and start over. Generally this larger pipeline with branch prediction lead to much better performance results. So what could go wrong?

Consider the branch statement:

 

if (x < array1_size)
    y = array2[array1[x] * 256];


This looks like a good bit of C code to test if an array is in range before accessing it. If it didn’t do this check then we could get a buffer overrun vulnerability by making x larger than the array size and accessing memory beyond the array. Hackers are very good at exploiting buffer overruns. But sadly (for hackers) programmers are getting better at putting these sort of checks in (or having automated or higher level languages do it for them).

Now consider branch prediction. Suppose we execute this code hundreds of times with legitimate values of x. The processor will see the conditional is usually true and the second line is usually executed. So now branch prediction will see this and when this code is executed it will just start execution of the second line right away and work out the first line in a second execution unit at the same time. But what if we enter a large value of x? Now branch prediction will execute the second line and y will get a piece of memory it shouldn’t. But so what, eventually the conditional in the first line will be evaluated and that value of y will be discarded. Some processors will even zero it out (after all they do security review these things). So how does that help the hacker? The trick turns out to be exploiting processor caching.

Processor Caching

No matter how fast memory companies claim their super fast DDR4 memory is, it really isn’t, at least compared to CPU registers. To get a bit of extra speed out of memory access all CPUs implement some sort of memory cache where recently used parts of main memory are cached in the CPU for faster access. Often CPUs have multiple levels of cache, a super fast one, a fast one and a not quite as fast one. The trick then to getting at the incorrectly calculated value of y above is to somehow figure out how to access it from the cache. No CPU has a read from cache assembler instruction, this would cause havoc and definitely be a security problem. This is really the CPU vulnerability, that the incorrectly calculated buffer overrun y is in the cache. Hackers figured out, not how to read this value but to infer it by timing memory accesses. They could clear the cache (this is generally supported and even if it isn’t you could read lots of zeros). Then time how long it takes to read various bytes. Basically a byte in cache will read much faster than a byte from main memory and this then reveals what the value of y was. Very tricky.

Recap

So to recap, the Spectre exploit works by:

  1. Clear the cache
  2. Execute the target branch code repeatedly with correct values
  3. Execute the target with an incorrect value
  4. Loop through possible values timing the read access to find the one in cache

This can then be put in a loop to read large portions of a programs private memory.

Summary

The Spectre attack is a very serious new technique for hackers to hack into our data. This will be like buffer overruns and there won’t be one quick fix, people are going to be patching systems for a long time on this one. As more hackers understand this attack, there will be all sorts of creative offshoots that will deal further havoc.

Some of the remedies like turning off branch prediction or memory caching will cause huge performance problems. Generally the real fixes need to be in the CPUs. Beyond this, systems like JavaScript interpreters, or even systems like the .Net runtime or Java VMs could have this vulnerability in their optimization systems. These can be fixed in software, but now you require a huge number of systems to be patched and we know from experience that this will take a very long time with all sorts of bad things happening along the way.

The good news for Raspberry Pi Raspbian users, is that the ARM in the older 32-Bit mode isn’t susceptible. It is only susceptible through software uses like JavaScript. Also as hackers develop these techniques going forwards perhaps they can find a combination that works for the Raspberry, so you can never be complacent.

 

Written by smist08

January 5, 2018 at 10:42 pm

Raspberry Pi Assembly Programming

with 2 comments

Introduction

Most University Computer Science programs now do most of their instruction in quite high level languages like Java which don’t require you to need to know much about the underlying computer architecture. I think this tends to create quite large gaps in understanding which can lead to quite bad program design mistakes. Learning to program C puts you closer to the metal since you need to know more about memory and low level storage, but nothing really teaches you how the underlying computer works than doing some Assembler Language Programming, The Raspbian operating system comes with the GNU Assembler pre-installed, so you have everything you need to try Assembler programming right out of the gate. Learning a bit of Assembler teaches you how the Raspberry Pi’s ARM processor works, how a modern RISC architecture processes instructions and how work is divided by the ARM CPU and the various co-processors which are included on the same chip.

A Bit of History

The ARM processor was originally developed to be a low cost processor for the British educational computer, the Acorn. The developers of the ARM felt they had something and negotiated a split into a separate company selling CPU designs to hardware manufacturers. Their first big sale was to Apple to provide a CPU for Apple’s first PDA the Newton. Their first big success was the inclusion of their chip design in Apple’s iPods. Along the way many chip makers like TI which had given up competing on CPUs built single chip computers around the ARM. These ended up being included in about every cell phone including those from Nokia and Apple. Nowadays pretty up every Android phone is also built around ARM designs.

ARM Assembler Instructions

There have been a lot of ARM designs from early simple 16 bit processors up through 32 bit processors to the current 64bit designs. In this article I’m just going to consider the ARM processor in the Raspberry Pi, this processor is a 64 bit processor, but Raspbian is still a 32 bit operating system, so I’ll just be talking about the 32 bit processing used here (and I’ll ignore the 16 bit “thumb” instructions for now).

ARM is a RISC processor which means the idea is that it executes very simple instructions very quickly. The idea is to keep the main processor simple to reduce complexity and power usage. Each instruction is 32 bits long, so the processor doesn’t need to think about how much to increment the program counter for each instruction. Interestingly nearly all the instructions are in the same format, where you can control whether it sets the status bits, can test the status bits on whether to do anything and can have four register parameters (or 2 registers and an immediate constant). One of the registers can also have a shift operation applied. So how is all this packed into on 32 bit instruction? There are 16 registers in the ARM CPU (these include the program counter, link return register and the stack pointer. There is also the status register that can’t be used as a general purpose register. This means it takes 4 bits to specify a register, so specifying 4 registers takes 16 bits out of the instruction.

Below are the formats for the main types of ARM instructions.

Now we break out the data processing instructions in more detail since these comprise quite a large set of instructions and are the ones we use the most.

Although RISC means a small set of simple instructions, we see that by cleverly using every bit in those 32 bits for an instruction that we can pack quite a bit of information.

Since the ARM is a 32-Bit processor meaning among other things that it can address a 32-Bit address space this does lead to some interesting questions:

  1. The processor is 32-Bits but immediate constants are 16-Bits. How do we load arbitrary 32-Bit quantities? Actually the immediate instruction is 12-Bits of data and 4 Bits of a shift amount. So we can load 12 Bits and then shift it into position. If this works great. If not we have to be tricky by loading and adding two quantities.
  2. Since the total instruction is 32-Bits how do we load a 32-Bit memory address? The answer is that we can’t. However we can use the same tricks indicated in number 1. Plus you can use the program counter. You can add an immediate constant to the program counter. The assembler often does this when assembling load instructions. Note that since the ARM is pipelined the program counter tends to be a couple of instructions ahead of the current one, so this has to properly be taken into account.
  3. Why is there the ability to conditionally execute all the data processing instructions? Since the ARM processor is pipelines, doing a branch instruction is quite expensive since the pipeline needs to be discarded and then reloaded at the new execution point. Having individual instructions conditionally execute can save quite a few branch instructions leading to faster execution. (As long as your compiler is good at generating RISC type code or you are hand coding in Assembler).
  4. The ARM processor has a multiply instruction, but no divide instruction? This seems strange and unbalanced. Multiply (and multiply and add) are recent additions to the ARM processor. Divide is still considered too complicated and slow, plus is it really used that much? You can do divisions on either the floating point coprocessor or the Neon SIMD coprocessor.

A Very Small Example

Assembler listings tend to be quite long, so as a minimal set let’s start with a program that just exits when run returning 17 to the command line (you can see this if you type echo $@ after running it). Basically we have an assembler directive to define the entry point as a global. We move the immediate value 17 to register R0. Shift it left by 2 bits (Linux expects this). Move 1 to register R7 which is the Linux command code to exit the program and then call service zero which is the Linux operating system. All calls to Linux use this pattern. Set some parameters in registers and then call “svc 0” to do the call. You can open files, read user input, write to the console, all sorts of things this way.

 

.global _start              @ Provide program starting address to linker
_start: mov     R0, #17     @ Use 17 for test example
        lsl     R0, #2      @ Shift R0 left by 2 bits (ie multiply by 4)
        mov     R7, #1      @ Service command code 1 terminates this program
        svc     0           @ Linux command to terminate program

 

Here is a simple makefile to compile and link the preceding program. If you save the above as model.s and then the makefile as makefile then you can compile the program by typing “make” and run it by typing “./model”. as is the GNU-Assembler and ld is the linker/loader.

 

model: model.o
     ld -o model model.o

model.o: model.s
     as -g -o model.o model.s

clean:
     rm model model.o

 

Note that make is very particular about whitespace. It must be a true “tab” character before the commands to execute. If Google Docs or WordPress changes this, then you will need to change it back. Unfortunately word processors have a bad habit of introducing syntax errors to program listings by changing whitespace, quotes and underlines to typographic characters that compilers (and assemblers) don’t recognize.

Summary

Although these days you can do most things with C or a higher level language, Assembler still has its place in certain applications that require performance or detailed hardware interaction. For instance perhaps tuning the numpy Python library to use the Neon coprocessor for faster operation of vector type operations. I do still think that every programmer should spend some time playing with Assembler language so they understand better how the underlying processor and architecture they use day to day really works. The Raspberry Pi offers and excellent environment to do this with the good GNU Macro Assembler, the modern ARM RISC architecture and the various on-chip co-processors.

Just the Assembler introductory material has gotten fairly long, so we won’t get to an assembler version of our flashing LED program. But perhaps in a future article.

 

Written by smist08

January 4, 2018 at 10:45 pm

C Programming on the Raspberry Pi

with 2 comments

Introduction

I blogged on programming Fortran a few articles ago, this was really a tangent. I installed the Code::Blocks IDE to do some C programming, but when I saw the Fortran support I took a bit of a side trip. In this article I want to get back to C programming on the Raspberry Pi. I’ve been a C programmer for much of my professional career starting at DREA and then later on various flavours of Unix at Epic Data and then doing Windows programming at a number of companies including Computer Associates/Accpac International/Sage. I’ve done a lot of programming in the object oriented extensions to C including C++, Java, C# and Objective-C. But I think at heart I still have a soft spot for C and enjoy the fun things you can do with pointers. I think there are a lot of productivity benefits to languages like Java and C# which take away the most dangerous features of C (like memory pointers and memory allocation/deallocation), I still find C to be very efficient and often a quick way to get things done. Admittedly I do all my programming these days in Python, but sometimes Python is frustratingly slow and then I miss C.

In this article we’ll re-implement in C our flashing LED program that I introduced here. We’ve now run the same program in Python, Scratch, Fortran and C. The Raspberry Pi is a great learning environment. If you want to learn programming on very inexpensive equipement, the Raspberry Pi is really excellent.

GCC and C

The Gnu Compiler Collection (GCC) is the main C compiler for Linux development and runs on many other platforms. GCC supports many programming languages now, but C is its original and main language. The GCC C Compiler implements the 2011 C language standard C11 along with a large collection of extensions. You can define compiler flags to enforce strict compliance to the standards to improve portability, but I tend to rely on GCC portability instead. A number of the extensions are very handy like being able to define the loop variable inside a for statement which is a feature from C++.

Code::Blocks

Although you don’t need an IDE to do C development, you can just edit the source files in any text editor then use GNU Make to do the build. Then run the GNU Debugger separately to do any debugging. But generally it’s a bit easier to use an IDE especially for debugging. Code::Blocks is a popular IDE that runs on the Raspberry Pi (and many other things), it’s fairly light weight (certainly compared to Eclipse, XCode or Visual Studio) and has all the standard IDE features programmers expect.

A number of people recommend programming on a more powerful computer (like a good Mac or Windows laptop) and then just transferring the resulting executable to the Pi to run and test. For big projects this might have some productivity benefits, but I find the Pi is up to the task and can quite happily develop directly on the Raspberry Pi.

Accessing the GPIO

From C you have quite a few alternatives in how to access the GPIO. You can open /dev/mem and get a direct memory mapping to the hardware registers. This requires running as root, but it is more direct. I’m going to go the same route as I did for the Fortran program and use the easier file access from the Raspbian GPIO device driver. This one works pretty well and doesn’t require root access to use. A good web page with all the ways to access the GPIO from various languages including C is here. If you want to see how to access GPIO hardware registers directly, go for it. Like the Fortran program I needed a delay after opening the main devices file and before accessing the separate file created for the GPIO pin. There seems to be a bit of a race condition here that needs to be avoided. Otherwise a fairly simple C program and accessing the GPIO is pretty standard as accessing Linux devices go.

C Code

Here is the C code for my little flashing lights program. Three source files main.c and then gpio.h and gpio.c for the gpio access routines.

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

#include “gpio.h”

int main()
{
   int i;
int sleepTime = 200000;

   if (-1 == GPIOExport(17) ||
        -1 == GPIOExport(27) ||
        -1 == GPIOExport(22))
   return(1);

   // Necessary sleep to allow the pin
   // files to be created.
usleep(10000);

   /*
    * Set GPIO directions
*/
if (-1 == GPIODirection(17, OUT) ||
        -1 == GPIODirection(27, OUT) ||
        -1 == GPIODirection(22, OUT))
       return(2);

   for ( i = 0; i < 10; i++ )
   {
        if (-1 == GPIOWrite(17, HIGH))
             return(3);
       usleep(sleepTime);
if (-1 == GPIOWrite(17, LOW))
            return(3);
       if (-1 == GPIOWrite(27, HIGH))
            return(3);
       usleep(sleepTime);
if (-1 == GPIOWrite(27, LOW))
            return(3);
       if (-1 == GPIOWrite(22, HIGH))
            return(3);
       usleep(sleepTime);
if (-1 == GPIOWrite(22, LOW))
            return(3);
   }
return( 0 );
}

// gpio.h

#define IN  0
#define OUT 1

#define LOW  0
#define HIGH 1

extern int GPIOExport(int pin);
extern int GPIOUnexport(int pin);
extern int GPIODirection(int pin, int dir);
extern int GPIORead(int pin);
extern int GPIOWrite(int pin, int value);

/* gpio.c
 *
* Raspberry Pi GPIO example using sysfs interface.
* Guillermo A. Amaral B. <g@maral.me>
*
* This file blinks GPIO 4 (P1-07) while reading GPIO 24 (P1_18).
*/

#include <sys/stat.h>
#include <sys/types.h>
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

#include “gpio.h”

int GPIOExport(int pin)
{
#define BUFFER_MAX 3
    char buffer[BUFFER_MAX];
    ssize_t bytes_written;
    int fd;

    fd = open(“/sys/class/gpio/export”, O_WRONLY);
    if (-1 == fd) {
         fprintf(stderr, “Failed to open export for writing!\n”);
         return(-1);
    }
    bytes_written = snprintf(buffer, BUFFER_MAX, “%d”, pin);
    write(fd, buffer, bytes_written);
    close(fd);
    return(0);
}

int GPIOUnexport(int pin)
{
    char buffer[BUFFER_MAX];
    ssize_t bytes_written;
    int fd;

    fd = open(“/sys/class/gpio/unexport”, O_WRONLY);
    if (-1 == fd) {
         fprintf(stderr, “Failed to open unexport for writing!\n”);
        return(-1);
     }

     bytes_written = snprintf(buffer, BUFFER_MAX, “%d”, pin);
     write(fd, buffer, bytes_written);
    close(fd);
    return(0);
}

int GPIODirection(int pin, int dir)
{
static const char s_directions_str[]  = “in\0out”;

#define DIRECTION_MAX 35
    char path[DIRECTION_MAX];
     int fd;

   snprintf(path, DIRECTION_MAX, “/sys/class/gpio/gpio%d/direction”, pin);
    fd = open(path, O_WRONLY);
    if (-1 == fd) {
        fprintf(stderr, “Failed to open gpio direction for writing!\n”);
        return(-1);
    }

    if (-1 == write(fd, &s_directions_str[IN == dir ? 0 : 3], IN == dir ? 2 : 3)) {
         fprintf(stderr, “Failed to set direction!\n”);
         return(-1);
    }
    close(fd);
    return(0);
}

int GPIORead(int pin)
{
#define VALUE_MAX 30
    char path[VALUE_MAX];
    char value_str[3];
    int fd;

    snprintf(path, VALUE_MAX, “/sys/class/gpio/gpio%d/value”, pin);
    fd = open(path, O_RDONLY);
    if (-1 == fd) {
        fprintf(stderr, “Failed to open gpio value for reading!\n”);
        return(-1);
    }

    if (-1 == read(fd, value_str, 3)) {
        fprintf(stderr, “Failed to read value!\n”);
        return(-1);
    }

    close(fd);

    return(atoi(value_str));
}

int GPIOWrite(int pin, int value)
{
static const char s_values_str[] = “01”;

    char path[VALUE_MAX];
    int fd;

    snprintf(path, VALUE_MAX, “/sys/class/gpio/gpio%d/value”, pin);
    fd = open(path, O_WRONLY);
    if (-1 == fd) {
        fprintf(stderr, “Failed to open gpio value for writing!\n”);
        return(-1);
    }

    if (1 != write(fd, &s_values_str[LOW == value ? 0 : 1], 1)) {
        fprintf(stderr, “Failed to write value!\n”);
        return(-1);
    }

    close(fd);
    return(0);
}

Summary

This was a quick little introduction to C development on the Raspberry Pi. With the GCC compiler, Code::Blocks, GNU Debugger and GNU Make you have all the tools you need for serious C development. I find the Raspberry Pi is sufficiently powerful to do quite a bit of development work with good productivity. As a learning/teaching environment its excellent. It’s really amazing what you can do with a $35 single board computer.

Written by smist08

December 23, 2017 at 10:48 pm

Fortran Lives

with 3 comments

Introduction

I was looking at a programming IDE called Code::Blocks that seems popular on the Raspberry Pi. Much lighter weight than Eclipse or Visual Studio, but it has a great deal of the same functionality including debugging, project templates, code highlighting and auto-complete. One thing that caught my interest was that Code::Blocks has direct support for Fortran programming. Back when I took first year Computer Science at UVic, all the programming labs were done in WATFIV (Waterloo Fortran IV) and then one of my Co-op work terms was at the the Institute of Ocean Sciences analysing experimental data from the Arctic, writing in Fortran using the extensive Fortran scientific and visualization libraries that were state of the art for the time (on a Univac mainframe).

One thing I noticed when playing with Machine Learning and Python programming was that if I installed something that didn’t have a binary for the particular flavour of Linux I was using then it would download the source code and compile that. What surprised me was the number of Fortran source files it would compile. Part of the reason for this is the giant library of efficient and well tested numerical libraries written in Fortran that have either been donated to the public domain or originated that way from various University research projects. It turns out that many of the popular array, numerical and algorithm libraries for Python are all written in Fortran and a large part of the popularity of Python is the easy access to all these libraries (like LAPACK).

GCC

Many people think of GCC just as the Gnu C compiler for Linux. However officially GCC stands for the Gnu Compiler Collection and supports C, C++, Objective-C, Objective-C++, Fortran, Java, Ada, Go and OpenMP. This then provides a great free cross platform compiler for Fortran that supports most of the things in the latest standard. As a result you can do Fortran programming easily anywhere including the Raspberry Pi. GCC is the compiler that the Code::Blocks IDE runs to compile your Fortran programs.

Fortran isn’t pre-installed on the Raspberry Pi, so to compile a Fortran program you need to add Fortran support to GCC which you do from a terminal window by:

sudo apt-get install gfortran

GPIO

I thought as an experiment I would port my simple flashing light program that I showed in Python and Scratch in my previous blog posting on breadboarding over to Fortran. So Python and Scratch come with GPIO libraries pre-installed and was really easy. For Fortran I didn’t see any such library, but fortunately for Unix/Linux you can usually access any hardware devices via the file metaphor. Basically you control the hardware by opening a file (usually in /dev) and then cause things to happen by writing various things to these special files. Similarly you read these files to get input or status. A good description of how to control the GPIO lines via files is given here. For instance if we want to turn on our LED we wired to pin 17, we would send 17 to the file /sys/class/gpio/export. We can do this from a terminal command line via:

echo 17 > /sys/class/gpio/export

This causes a number of files under /sys/class/gpio/glio17 to be created that we can now access. First we setup pin 17 for output via:

echo out > /sys/class/gpio/gpio17/direction

Then we turn pin 17 on via

echo 1 > /sys/class/gpio/gpio17/value

And turn it off via:

echo 0 > /sys/class/gpio/gpio17/value

Since most programming languages have file I/O libraries, under Linux this then makes most devices accessible.

Fortran Code

Creating the program was quite easy. I found a library on the Web that provides the GPIO access via the files which I’ll list later. The only problem was that the Fortran sleep function takes its parameters only in seconds so you can’t do a sub-second sleep which means the LEDs flash very slowly. Fortunately it turns out that you can call C runtime routines from Fortran fairly easily, so I include the interface to the C usleep (sleep in microseconds) function so we can use the same 0.2 second time between flashes that we used before. Below is the Fortran source code:

 

! Flash the GPIO lights
program main
  use gpio
  implicit none
  interface
     subroutine usleep(useconds) bind(C)
      use iso_c_binding
      implicit none
      integer(c_int32_t), value :: useconds
     end subroutine
  end interface
  integer i, sleepTime

  call gpioSetOut(17)
  call gpioSetOut(27)
  call gpioSetOut(22)

  sleepTime = 200000

  do i = 1, 10
    call gpioOutput(17, 1)
    call usleep(sleepTime)
    call gpioOutput(17, 0)
    call gpioOutput(27, 1)
    call usleep(sleepTime)
    call gpioOutput(27, 0)
    call gpioOutput(22, 1)
    call usleep(sleepTime)
    call gpioOutput(22, 0)
  end do
end


Fortran has evolved a bit since my University days. There are full structured programming constructs, so you don’t need to use labels. Notice the DO loop has a DO END rather than specifying a label on a CONTINUE statement as we used to do. Fortran has added good support for modules and even object oriented programming while maintaining compatibility for all those scientific libraries everyone loves so much.

Now the GPIO module which I found here. This shows how to create a nice Fortran module. It also shows some Fortran string processing. The module didn’t work for me directly, I had to add a sleep statement after allocating the GPIO pin to allow time for the files to be created or I got file access errors. Here is the code:

 

module gpio
    implicit none
    contains
    subroutine gpioSetOut(pin)
        integer, intent(in) :: pin
        character (len=35) :: unexportChar
        character (len=33) :: exportChar
        character (len=45) :: directionChar
        write (unexportChar, '("echo ", I0, " > /sys/class/gpio/unexport")') pin
        write (exportChar, '("echo ", I0, " > /sys/class/gpio/export")') pin
        call execute_command_line(unexportChar)
        call execute_command_line(exportChar)
        call sleep(1)

        write (directionChar, '("echo out > /sys/class/gpio/gpio", I0, "/direction")') pin
        call execute_command_line(directionChar)
    end subroutine gpioSetOut

    subroutine gpioSetIn(pin)
        integer, intent(in) :: pin
        character (len=35) :: unexportChar
        character (len=33) :: exportChar
        character (len=45) :: directionChar
        write (unexportChar, '("echo ", I0, " > /sys/class/gpio/unexport")') pin
        write (exportChar, '("echo ", I0, " > /sys/class/gpio/export")') pin
        call execute_command_line(unexportChar)
        call execute_command_line(exportChar)
        call sleep(1)

        write (directionChar, '("echo in > /sys/class/gpio/gpio", I0, "/direction")') pin
        call execute_command_line(directionChar)
    end subroutine gpioSetIn

    subroutine gpioOutput(pin, value)
        integer, intent(in) :: pin, value
        character (len=45) :: valueChar

        write (valueChar, '("echo ", I1, " > /sys/class/gpio/gpio", I0, "/value")') value, pin
        call execute_command_line(valueChar)
    end subroutine gpioOutput

    subroutine gpioRead(pin, value)
        integer, intent(in) :: pin
        integer, intent(out) :: value
        character (len=28) :: valueChar

        write (valueChar, '("/sys/class/gpio/gpio", I0, "/value")') pin

        open (unit=1, file=valueChar)
        read (1,*) value
        close (1)
    end subroutine gpioRead

end module gpio


One other thing, I needed to add -lgfortran as a linker option in Code::Blocks, since for some reason a freshly created Fortran application project didn’t include the link for the Fortran runtime.

Fortran Evolution

The latest standard for Fortran came was Fortran 2008 which came out in 2010. The next version will be Fortran 2018 and we’ll see if it shows up next year. GCC supports most things in Fortran 08 plus a few other enhancements. The next 2018 release is includes quite a few things including more advanced parallel processing capabilities and easier interoperability with C. Certainly Fortran has made great strides since my University days with structured, modular and object oriented programming support along with variable length string processing. Fortran really excels at parallel processing support since it is still the goto language on most supercomputers and used for all those advanced climate, astronomical and other scientific models.

Summary

I think I’ll stick to Python as my current goto language. But playing with Fortran was fun and it’s amazing to see how much usage it still gets. If you are doing serious high performance numerical processing then you are probably going to have to get your hands dirty with Fortran. Certainly the Raspberry Pi is a good place to learn Fortran with high quality free tools like Code::Blocks and GCC Fortran.

 

Written by smist08

December 2, 2017 at 4:39 pm