Some time ago I was confronted by the question: how to set the version of gcc used in a Yocto build (or g++, or any other software commonly referred to as the "toolchain" - a set of compilers and other tools used for the sole purpose, of building the target, which itself isn't installed on the target). This is a trivial issue for a developer working on a simple application without a complicated dependency tree, but in embedded systems development, where we build entire system images, even a slight modification to the toolchain often has enormous impact on the entire build, to the effect that the system will often fail to compile with that new toolchain.
One of the most important things that I've recently realized is that my intentions matter. There is a well-known piece of folk wisdom that when you feel like correcting someone, or you want to offer them advice, or more generally get involved in someone's endeavor, you should only do so if your primary intention is to genuinely help that person. Like most folk wisdom, this piece of advice is subject to criticism by those who think they can reason their way out of the problem. If I'm offering to help you, what does it matter if I'm doing it because I want you to get better, or if I'm doing it for money, or to earn your and other people's respect, or to make you feel stupid, or to make you admire me, or to make you attracted to me? If the net effect is that your life has improved, are we not right to conclude that it doesn't matter what my personal motive for helping you is?
The term "variadic" (or "variable", see footnote) functions refers to functions whose number and types of arguments are not known at compile time. Instead, the function infers them from its input. This is the kind of C hackery that one encounters early in one's exposure to the C language (the classic example being the printf() function), and yet for many non-C programmers and beginning C programmers, the mechanism by which such functions operate is covered by a veil of mystery. This post is not meant to be a tutorial on how to use the C library interface for variadic functions (although I describe that too). The point is to make educated guesses about what the implementation of such an interface might look like, and see if I can write a variadic function that works without using this interface.
Self control is a crucial aspect of any person's life. It is (as measured by the conscientiousness dimension in the Big Five model - see footnote at the end of the article) a good psychometric predictor of success at work (people who have self-control work harder), health and longevity (they eat more healthy food and exercise more), and relationship quality (they are able to make sacrifices required to stay in a long-term relationship).
I wanted to understand the recent privilege escalation (escape from a container) vulnerability in runc (the runtime used in Docker), so I sat down looking through the original blog post by Adam and Borys and wrote and own PoC. I had a lot of fun doing this, I hope someone finds this insightful/useful.
My Ubuntu 16.04 LTS was getting a bit rusty (and it refuses to upgrade to a new release), so I was looking for a new distro for some time. I had already used Debian and Fedora in the past and was considering giving OpenSUSE a try. When I was asking for opinions on OpenSUSE, several friends came up with different suggestions and one of them said that if I wanted something "out there", I should try Fedora Silverblue.
Here are some more cool talks from 35C3 that I watched online after the event. This text is a continuation of my previous post about the last Congress.
Last month, I attended the 35th Chaos Communication Congress (35C3), one of the leading hacking conferences in Europe. I decided to write a short comment for each of the talks that I went to, to kind of describe the overall feel of the event.
Common memory safety bugs mitigation techniques include marking memory pages as non-executable (the so called NX bit), address space layout randomization (ASLR) and stack canaries (which specifically protect against buffer-overflows; they are sometimes referred to as "stack cookies").