Encrypting Linux’s home directory is usually the first thing people worried about their personal data do. However, this approach comes at the cost of: (i) slower booting, (ii) problems when rebooting remotely and ssh-ing the machine straightway (more about this in the post), and (iii) the necessity to place all sensitive information in the home directory. In this post I will show another way to keep sensitive information encrypted, which – in my view -, is simpler and more secure.
Lately, I am spending quite some time verifying Open-Cannel SSD hardware prototypes in the context of LightNVM. A great deal of these tests is about benchmarking performance (iops) and latency, for which I use fio. Fio is a great tool to test specific I/O patterns. However, when wanting to benchmark a range of I/O configurations in different setups, it is very convenient to automatize the process. In this post, I present a simple python script that allows to automatize fio tests as a function of block size, number of jobs, I/O depth, etc. and stores the test results in csv format. Also, in order to account for variances, the script supports replicating each fio test a configurable number of times, being the average of these the one being stored.
I use my MacBook as my main machine from which I access daily a number of servers that I use for development, experimentation, and maintenance. Since I do all my job from the terminal, I end up using SSH extensively. One major issue I have encountered is that SSHing different servers entails (i) having a mental map of which terminals correspond to which machines, and (ii) the overhead of introducing a SSH line immediately after opening a new terminal window. Although this can be mitigated by merely using zsh’s substring history search, aliases, etc., I found it easier to offload the responsibility to my muscle memory. In this post, I will describe my setup which, after over a month of being in production, has proved to make my life easier.
I use vim for development. More concretely, I use YADR, a fork of dotfiles for my zsh, git, vim, etc. setup. One of the vim plugins that I use the most is neocomplete, which provides simple but powerful autocompletion. One of the last commits in neocomplete introduces a problem that impedes correctly wrapping lines – normally set to 80 characters (issue here). It turns out that it was vim, not neocomplete that triggered this unwanted behaviour. This vim patch, fixes the issue, but the binary cannot be obtained for neither MacOS nor Ubuntu – which are my main OSs – via standard repositories. Thus, I decided to find a way to keep my vim updated so that I can easily patch future problems.
Open Virtualization (OV) is the first open software implementation of a Trusted Security Environment (TEE) for ARM TrustZone hardware security extensions as specified in Global Platform’s TEE Specification.. Sierraware is the company behind it. Since I first knew of OV I have had a great interest in using it for my research, and therefore I have spent some time understanding it and improving it to work with the boards we work with – the Xilinx’s ZC702. This efforts are now materialized in a git repository, under a GNU v2.0 License.
If you use Mac OS for development and have ever experienced that cloning a GIT repository produces instant non staged changes for commit then this is your post. Here I will explain the underlying problem for this GIT weird behaviour and propose 2 solutions: (i) lazy i-don’t-want-to-format-my-mac, and (ii) I want to do things right. So, let’s get started.
A couple weeks ago I posted my new working environment: YADR + iTerm2 . I am still loving it, and in fact it gets better and better as one gets used to the shortcuts and the new functionality that was simply not there before! The problem is that due to all that many new shortcuts + the chances of you messing up when typing something wrong in vim, I keep finding myself in google or egreping my YADR tree very often. This post is therefore as much for myself as for anybody in the same situation as me: A compilation of shortcuts and useful commands that make my/your life easier. Continue reading
About a month ago my group purchased the Xilinx Zynq-7000 SoC ZC702 Evaluation Kit, featuring the ZC702 SoC board. Far from being trivial, getting the SDK and the framework (ISE Design Suite 14.x + ARM Tools) to work properly in a stable environment is quite challenging. In this post I will go through the different alternatives, describing the pros and cons I considered. I will also propose a mixed set-up combining 2 virtual machines, as well as a step-by-step guideline for it. This configuration is actually the one I am using for programming the ZC702.
Once we have understood how our device boots up, we will then cover the technical aspects of how to flash our device. As in the boot sequence, the 3 main components that need to be transferred -“flashed”- to the board, are: The Bootloader, the Kernel and the OS (Android). We will cover them in different posts, starting here with The Bootloader.
Some weeks ago, I started working with Android, not as an application developer, but as a platform one. What does this means? Under any Android there is a great deal of things that need to work in order to be able to run whichever app we can think of – from a game to e-banking.