BeagleBoard Black (BBB) and GPIO

When you buy a Beagleboard Black (a.k.a. BBB), it comes with a pre-installed version of debian with more or less everything you need to get started. I purchased the board for another purpose and develop seL4 components on top of it. But before starting to develop on seL4, it is useful to know exactly how the board works: once you know how the board works, you can start to write your code and know for sure that the bug comes from your code.

In this article, I will explain quickly how to set up a simple circuit to test the GPIO of the beaglebone.

cape-headers-digital.png
Mapping between pin numbers and GPIO ID from bone 101

Setting up the circuit

To test the circuit, you need only a breadboard, a resistance and a LED. Simple.

Connect the PIN 14 (which is mapped to GPIO id 50, see table) from bank P9 (green cable on the picture) on the breadboard. Connect it to a resistance and a LED. The other pin of the LED is then connected to the ground (last PIN of P9).

board
Wiring scheme of the example

 

Controlling the GPIO in Linux

In Linux, the GPIO can be controlled using the SysFS abstraction layer. You can access it through /sys/class/gpio. I am using the pre-installed debian software on the board.

To control a particular pin, you must export it. You do it by writing the value of the pin you want to export into /sys/class/gpio/export. Then, a new directory is /sys/class/gpio/gpio<PIN-NUMBER> is created with many different files to control the pin (direction, value, etc.).

In our example, the pin 14 from the bank P9 correspond to GPIO 50. You can see the corresponding mapping between the pin and GPIO number in the beaglebone 101 document.

So, let’s start by exporting this pin:

echo 50 > /sys/class/gpio/export

Then, a new directory /sys/class/gpio/gpio50 is created.

Let’s set its direction to out

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

And let’s set its value to 1

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

 

And finally, if you want to make the LED blinks every second, you can use this command:

while [ 1 ]; do echo 1 > /sys/class/gpio/gpio50/value ; sleep 1 ; echo 0 > /sys/class/gpio/gpio50/value ; sleep 1 ; done

 

 

Sources

Advertisements
BeagleBoard Black (BBB) and GPIO

Work & Injury

This week, a new blog post about my ongoing work on software security has been published on the SEI blog. This work is being very exciting and I am currently working on other publication. During the next week, I will also work on a code generator that will transform an architecture model into C code executed on top of seL4, the only formally verified kernel that has been used for the HACMS program from DARPA. This will facilitates the design, implementation and verification of secure systems.

Screenshot 2016-02-04 at 11.11.07 PM

On a running side, running is becoming so painful that I no longer enjoy it. Every step is painful. A pause is necessary after every mile.

I need a new strategy to recover, avoid any permanent damage and maintain my fitness level. But running is no longer an option.

More on that soon.

Work & Injury

Bonjour Toulouse

After some days in the country side, it is now time to head to Toulouse to give a tutorial during the formal method day at the LAAS lab and present one research paper at ERTS 2016. I had a last run in Normandy this morning.

Road in Normandy in the Morning
Road in Normandy in the Morning

My right leg is definitively destroyed. The repeated long runs on pavement in Prague had a cost I am paying right now. After reaching my weekly goal of 60 miles, I might take some time off: too painful to run, it feels it might eventually hide more serious damages.

In the meantime, Francois d’Haene won HK100. No kidding.

D'Haene finishing strong HK100 (photo irunfar)
D’Haene finishing strong HK100 (photo irunfar)

Congratulations dude!

Bonjour Toulouse

Back to my roots

I came back home for few days in my hometown in france.

Went for a run, exploring the trails around.

Should finally run my 60 miles-week.

Back to my roots. For some days.

And it feels good.

 

home
Good Morning from Le Neubourg, France

 

And of course, my family got everything I like. It seems they understand now that my heart is definitively not in this part of the world.

 

pb

Back to my roots

It is an architecture problem

The big news today (that got my attention!) is the Washington post about Linus’ thoughts on security, especially in the linux kernel.You probably do not know but today, Linux is one of the most used kernel in the world. Every Android device rely on it – most of non-critical embedded devices use it. You are probably not aware of it but you are probably using more Linux-powered devices than Windows or Mac.

The article is well written and explain most of the issues to a non-technical people. Great. But sometimes, it messes things up. For example, when the article reports that the ashley madison data breach, it is totally unrelated: the article focuses on the kernel, not the userspace. This is just not accurate to connect this attack with the linux kernel, it could happen with the same software running on a different kernel.

What users must understand is that security comes at a cost and while this is an important requirement for us, this is not the most critical and people do not pay attention to it until a big attack appears. Achieving high security impact other requirements and characteristics, such as performance. At the end, the question is: are you willing to have your system running slower to protect yourself against a potential security attack against your contact list that has not been discovered yet and would be fixed as soon as it is discovered?

Are you willing to pay the cost of security without affecting other attributes?

It totally depends on your objective and priorities: if your system is a smartphone, you probably do not care because once discovered, the attack will be fixed and your phone will be automatically upgraded. But if you design a nuclear power plant, there is no room for a second chance, millions of people are already dead. So, you do not want that to happen at any cost.

Linus made a good point on that as well: if you are running a safety-critical system, you just do not use Linux. If you are concerned about the security of Linux, solutions exists (e.g. selinux, grsecurity). And if tomorrow the kernel needs more security, the community will work the existing kernel and add the necessary layers – this is just that it has not been the focus so far or has been done through individual efforts. But at the end, if you really want to isolate software according to their criticality, this is no longer a matter of code but an architecture concern: you have to design your system and isolate components according to their security levels. Many existing approaches address that issue (for example, MILS) and there are many solutions to such design: gatekeepers (filtering insecure data before they are forwarded to the secure components), physical or logical separation, etc.

This is also what has been shown by the attack on the Jeep by Miller and Valasek: the entertainment system is connect to several networks connecting critical and non-critical devices without any filtering. By attacking the entertainment system, attackers were able to control a car from their couch. Great. Some will argue this is a software issue but I am still convinced this is an architecture issue: the entertainment system should not be connected to critical equipment without any filtering or protection mechanism.

The Washington post article is interesting but the whole discussion on the Linux kernel is just too much. Rather than putting the fault of an insecure Internet on linux developers, it would rather be more interesting to understand the real architecture defects of the network. And why people choose such insecure software: if Linux is so bad, why is it still soused? There are still many open questions but this article demonstrates how cybersecurity is not understood and addressed today, in our now over-connected world.

It is an architecture problem

Change takes time

When multi-core processors were released in the mid-2000s, developers had to face a new programming paradigm: multi-threading. For sure, SMP (Symmetric Multiprocessing) was already there since years but such machines were dedicated to particular applications.

This new processor design had some side effects: since applications were no longer executed on a single processor and developers had to synchronize shared data and avoid what we call race condition. Interestingly,  most of the time, a race condition will crash the application. When multi-core processors were introduced, many popular applications had such issues (see this discussion for iTunes) – mostly because developers did not design an application with synchronization constraints in mind. Of course, now, this design constraints is understood by most developers.

During a current project, I am investigating the common software vulnerabilities/weaknesses and their evolution over time. Among the most popular, the “race condition” issue. There is the picture.

number of issues related to synchronization issues
Number of issues related to synchronization issues

If we look closely, there was very few reports until multi-core were introduced. It continues to increase until 2012 (why it decreases in 2011 is still unknown) and then start to decrease. Interestingly, there are still a lot of issues related to synchronization today.

The take away from this data? Change takes time. A. Lot. It took almost 10 years for software developers to address the matter and stop writing buggy code. And there are still a lot of reported issues. Developers had to take this new constraint into account while they were not familiar with this paradigm. Teachers had to explain this issue and address the matters in class.

Change takes time and it is very difficult to predict the impact of a change – I assume nobody assumed that it would take so long for the industry to adapt to this new constraint.

Change takes time

There is no magic. Mostly hard work.

On my way to Seattle yesterday (and the Baker Lake Classic 25K – race report to come), I watched this TED talk by Bel Pesce. This synthesizes exactly a lifestyle, what you need to make your dreams happen, redefine your goals and continue the journey. It is probably one of the best TED talk I have watched so far, I wanted to share it with the readers of this blog, I hope you’ll enjoy it.

 

There is no magic. Mostly hard work.