Crypto-Gram, June 2016 (in EPUB and MOBI format)

English

Crypto-Gram is a famous free monthly newsletter written by the security expert Bruce Schneier. The original is available at Bruce Schneier’s website; this is the same content in MOBI and EPUB format, suitable for e-book readers.

Download

Posted in cryptogram, ebook, english | Tagged , , , , , | Leave a comment

Crypto-Gram, April 2016 (in EPUB and MOBI format)

English

Crypto-Gram is a famous free monthly newsletter written by the security expert Bruce Schneier. The original is available at Bruce Schneier’s website; this is the same content in MOBI and EPUB format, suitable for e-book readers.

Download

Posted in cryptogram, ebook, english | Tagged , , , , , | Leave a comment

Crypto-Gram, April 2016 (in EPUB and MOBI format)

English

Crypto-Gram is a famous free monthly newsletter written by the security expert Bruce Schneier. The original is available at Bruce Schneier’s website; this is the same content in MOBI and EPUB format, suitable for e-book readers.

Download

Posted in cryptogram, ebook, english | Tagged , , , , , | Leave a comment

Crypto-Gram, March 2016 (in EPUB and MOBI format)

English

Crypto-Gram is a famous free monthly newsletter written by the security expert Bruce Schneier. The original is available at Bruce Schneier’s website; this is the same content in MOBI and EPUB format, suitable for e-book readers.

Download

Posted in cryptogram, ebook, english | Tagged , , , , , | Leave a comment

Playing around with strace

English

From the strace manpage: “strace is a useful diagnostic, instructional, and debugging tool”.

Thanks to strace it’s possible to check what a program is doing by looking at the system calls that it makes. As a simple example, let’s compare what happens when running two “Hello, world!”, respectively with PHP and with Python.

The source codes of the two programs are the following:

ciao.py:

print "Ciao"

ciao.php:

<?php
echo "Ciao\n";

Let’s run them via strace:

$ strace -o py.txt python ciao.py
$ strace -o php.txt php ciao.php

Both programs will write “Ciao” in the console and terminate. As a side effect, strace will record every syscall made by both programs in the respective output files. Let’s peek at the strace logs to compare what happens when running the two toy scripts.

Everything begins from an execve call, that starts the interpreter:

execve("/usr/bin/php", ["php", "ciao.php"], [/* 59 vars */]) = 0
execve("/usr/bin/python", ["python", "ciao.py"], [/* 59 vars */]) = 0

Right after, the flow goes ahead by loading the shared libraries required by each interpreter. For example, php loads a shared library like this:

open("/lib/x86_64-linux-gnu/libz.so.1", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360\35\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=104824, ...}) = 0
mmap(NULL, 2199880, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f9c4e3db000
mprotect(0x7f9c4e3f4000, 2093056, PROT_NONE) = 0
mmap(0x7f9c4e5f3000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x18000) = 0x7f9c4e5f3000

As you can see, the shared library file’s content (in ELF format, can you see the header?) the is read and loaded in memory.

Python does more or less the same:

open("/lib/x86_64-linux-gnu/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340`\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=142080, ...}) = 0
mmap(NULL, 2217232, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f8a44489000
mprotect(0x7f8a444a1000, 2097152, PROT_NONE) = 0
mmap(0x7f8a446a1000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x18000) = 0x7f8a446a1000
mmap(0x7f8a446a3000, 13584, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f8a446a3000

Most of the syscalls are about loading the shared libraries. Both PHP and Python load the shared libraries linked to their executables. After that, other shared libraries are loaded:

  1. For PHP, the PHP extensions configured in the php.ini are loaded, and for each extensions, the shared libraries that it depends upon.
  2. Python scans the PYTHONPATH and loads some shared libraries located in there.

After the shared libraries galore, the script file to be run is loaded in memory:

open("ciao.php", O_RDONLY) = 4
fstat(4, {st_mode=S_IFREG|0664, st_size=21, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f9c4e815000
read(4, "
open("ciao.py", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0664, st_size=13, ...}) = 0
Inappropriate ioctl for device)
lseek(3, 0, SEEK_CUR) = 0
fstat(3, {st_mode=S_IFREG|0664, st_size=13, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f8a448c7000
read(3, "print \"Ciao\"\n", 4096)

As you can see, apparently both PHP and Python read their scripts by chunks of 4k each.

The interpreter can now execute the program text. Both PHP and Python ultimately, after approximately 1000 syscalls, end up doing exactly the same write operation:

write(1, "Ciao\n", 5)

This can be read as: write to the standard output (file descriptor no. 1) the string “Ciao\n” (the “\n” is explicit in the PHP echo and implicit in python’s print), which is 5 characters long.

And that’s it!

strace’s output can be quite dense (there are a lot of options to filter it – or to make it denser), but it’s incredibly useful to quickly see what happens when running a program (it can also be used to inspect already running programs, just by specifying the desired process-id). It’s surely worth to have it in your toolbelt.:-)

Posted in english, linux | Tagged , , , , , | Leave a comment

Crypto-Gram, February 2016 (in EPUB and MOBI format)

English

Crypto-Gram is a famous free monthly newsletter written by the security expert Bruce Schneier. The original is available at Bruce Schneier’s website; this is the same content in MOBI and EPUB format, suitable for e-book readers.

Download

Posted in cryptogram, ebook, english | Tagged , , , , , | Leave a comment

The physics of software

English

Published on Ingenium n. 102, April-May 2015
Journal of the Terni’s Order of Engineers
(Cineca-MIUR n. E203872)

Software engineering is a young discipline, with solid scientific basis in several fields of mathematics and in some fields that pertain strictly to computer science (e.g. relational database theory and compiler theory). Still, software engineering is a fertile ground for “snake oil salesmen”: when facing a problem to be solved it’s easy to find scores of experts (gurus, mentors) that promote the fashion-du-jour as the definitive panacea.

The comparison with other engineering disciplines is depressing. In civil engineering, for example, the materials and their shape are (or should be) chosen on the basis of a solid corpus of scientific knowledge: the forces that the structures will need to face and the different properties of materials (e.g. elasticity), that describe their behavior in reaction to such forces. Is it better iron or an alloy of iron, carbon and chromium? The correct answer is that that the question is ill-posed, it depends on the problem at hand! But if you ask a sample of (more or less aware) software engineering practitioners and ask them: is it better functional programming or object oriented programming? Is it better Java or C#? Rest assured that you will almost always get sharp and heartfelt answers: for the most part, nowadays, software engineering is nothing more than a rhetoric exercise, while an argument about the material and the shape to be used in a physical construction can be resolved without endless debates just by the accurate usage of physics and material science. If we consider the laws of physics, in fact, it would be pointless to build an house by using glass only (“it’s brighter!”) or bricks only (“it’s stronger!”): the usefulness of the materials depends on the context. And yet, while developing software, this happens often: we build an “house” by using “bricks” only, or by using “glass” only.

From several years Carlo Pescio, a well-known Italian software engineering professional, is trying to create a basic theory that he named “physics of software”: the software is considered as a material, while the software design (at every level) is considered as the process of shaping the software/material in the most appropriate way to solve the problem at hand. If we adopt this point of view, and we try to draw an analogy with material sciences, we must ask ourselves: what do we know about the software/material properties and about the “forces” that it must withstand? Not much, so far. In the software engineering knowledge body we mostly find:

  • Principles and methods: more or less dogmatic practices, stripped out of their original context and risen to the rank of principles; the process of stripping the context away makes such principles ill-defined and/or superfluous.

  • Patterns and reference designs: catalogs of design techniques to solve specific problems.

  • Metrics: software properties that can be measured more or less easily, but whose clarity and usefulness in the software design process are rather questionable. They may look similar to the aforementioned material’s properties, but they are not defined as a direct reaction to specific “forces”.

  • -ilities: reliability, scalability, maintainability etc. At first glance they may look like the aforementioned physical material’s properties, but they are fundamentally different: their definition is too generic (they are not defined as reactions to “forces”), so they cannot be measured in a meaningful way. Saying that a software is “scalable” is more like saying that a car is “safe”, but it’s completely different from describing the resistance of a metal alloy to a compression force.

In other words, while the analogy “software”/”material” and “software design”/”material shaping” is very clear, we still don’t have any idea about the software properties and about the “forces” that determine such properties. In his work about the “physics of software”, Carlo Pescio tries to explore this aspects, by defining something that we can call a “basic physics” for the software: a theory of software properties and forces.

Don’t let the metaphor mislead you, though, because the software’s nature is rather peculiar: software is executable knowledge, designed to be interpreted both by humans, that write and read programs, and by computers, that must run them to obtain the desired results. So, even if the physics of materials was the inspiration for this research, the model that Carlo Pescio is building looks more like quantum physics.

Currently, his “physical” software model is based on two main concepts:

  1. The software exists in three spaces: the decision space (the design’s product), the artifact space (the coding’s product) and the run-time space (the product of the program’s execution by a computer).
  2. The concept of “entanglement“, borrowed directly from quantum physics. The entanglement is a link between components that, with different modes of interaction, characterizes software in each of the three aforementioned spaces.

By starting from these two concepts, plus a few other basic ones, it is possible to derive most of principles and patterns that are the current written and spoken tradition of software engineering.

Carlo Pescio’s research on the “physics of software” is documented on the website www.physicsofsoftware.com. From some time the author has taken a pause from publishing his ideas, also because of their poor reception (it cannot be otherwise, in a world filled by the background noise of gurus and mentors, remember?). Still, his research is essential for the evolution of software engineering: the results that he published on his website are a great starting point to meditate deeply about the nature of software engineering. Let’s hope that we can read the next chapters soon!

Posted in coding, english, my writings | Tagged , , , , | Leave a comment