Hi there!

Welcome to Javier Lopez-Gomez’s personal site :wave:! I’m a HPC software engineer, Ph.D. in Computer Science and Technology, and exCERNie (@root-project), passionate about C++, OS internals, and compiler design / implementation.
You can read a bit more about me here. A summarized version of the CV (résumé) can be downloaded here.

Ideally, this site will also host posts about a number of interesting topics.

libledmtx-1.1.0 is out

As mentioned a few weeks ago, a number of new features were planned for libledmtx. This short follow-up post is an announcement of those features being officially available as of today. The new version has been tagged libledmtx-1.1.0. In particular, it brings:

  • Support for double buffer (see documentation for ledmtx_setbackbuffer() and ledmtx_swapbuffers()).
  • Allow for user-defined viewport (see ledmtx_setviewport()). This makes it possible to allocate a larger framebuffer than the physical display and change the visible surface as many times as needed.
  • Small optimizations regarding CPU time and access bank memory usage.
  • A test suite based on lit and gpsim.

Find more details here.

Resuming development of libledmtx

It has been a bit hectic in the last few months (and consequently a bit quiet here too). Here is some news: after a long period without any functional changes, I’d like to announce that the addition of some new features in libledmtx is scheduled for the next few weeks. Such features are mostly required for p18-LEDcube, but also useful for a future p18clock firmware update.

Specifically, the planned features are:

  • Support for double buffer. In this configuration, the driver reads from the frontbuffer, whereas the framebuffer manipulation routines act on the backbuffer. Once the backbuffer is ready, buffers can be swapped by using ledmtx_swapbuffers(). This in turn would enable viewports over the frontbuffer, i.e. having a frontbuffer larger than the actual display and only make a specific region visible.

  • Minor optimizations, mainly affecting the r393c164 driver. Small memory savings in the access bank are also expected.

  • Introduction of tests based on lit and the gpsim Microchip PIC simulator, enabling the validation of the library without relying on real hardware.

That’s all for now! Stay tuned!

Interesting reads on development in kernel-mode

This short post is about giving kudos to those books on the intricacies of kernel-mode that had an enormous impact on me and that were especially relevant for the implementation of my B.Sc. thesis around a decade ago. Without further ado, here is the list:

  • Understanding the Linux kernel: describes foundational concepts of the Intel x86 architecture and a in-depth view of the design of the Linux kernel. While the 3rd edition applied for Linux 2.6, it is still a valuable source of information.
  • Linux Device Drivers: this book can be seen as the practical counterpart of the previous book.
  • Designing BSD Rootkits: An Introduction to Kernel Hacking: one of the books that impressed me the most. Short and to the point explanation of rootkit mechanics, e.g. direct kernel object manipulation (DKOM) and kernel object hooking.

Happy reading!

Contemporary, a contributed theme for moderncv

Since 2012, I have been using the moderncv LaTeX package to prepare my CV. The moderncv class noticeably reduces the time required to typeset a nice-looking CV, yet it lacks an eye-catching modern theme.

In the last few days, I have been reworking my résumé and I took the chance to write a new theme that looks more up-to-date (see image). contemporary is largely based on the classic theme and makes use of PGF/TikZ for some of the decorations. A pull request for moderncv is up here. Enjoy!

Talk: git, from noob to expert

Back in 2019, during my doctoral studies, I was asked a number of git-related questions here and there by some members of the research group. Thus, I decided to prepare a slide deck for a talk/workshop to boost casual users’ knowledge. The talk covers git foundational concepts (e.g., blob / tree / commit objects, refs, index), as well as a quick overview of usual porcelain commands and scratching the surface of the plumbing layer.

Due to the general interest, the talk was given not only for the members of the ARCOS-UC3M research group, but also for other audiences. The slides are up here, just in case it can help other people :slightly_smiling_face:!

Fuzzing Against the Machine

Some months ago, my friends Antonio Nappa (@jeppojeps) and Eduardo Blázquez (@Fare9) finally released the book “Fuzzing Against the Machine”, for which I had the pleasure to write a foreword. The book covers fuzzing of embedded systems’ firmware leveraging tools such as QEMU and AFL / AFL++, with practical examples of vulnerability discovery on iOS, Android, and Samsung’s Mobile Baseband software, Shannon.

If you are interested in the topic, do not hesitate to take a look. The book is available on Amazon and Direct Digital (Packt).

Restoring the PCI configuration space of a device

Sometimes it’s useful to be able to restore the registers comprising the configuration space of a given PCI device to a known state, e.g. by the boot loader (so that the booted kernel finds the device in a specific state). To address this need, I wrote a simple script that generates a bunch of setpci commands compatible with setpci(8) (from the pciutils package) and GRUB2’s setpci command.

It takes a single argument in any of the forms taken by lspci -s, i.e. [[[[<domain>]:]<bus>]:][<device>][.[<func>]] that specifies the address of a device (or group of devices) whose configuration space is to be dumped, e.g.

# 0000:00:1f.3 is a 'Multimedia audio controller: Intel Corporation Tiger Lake-LP
#                    Smart Sound Technology Audio Controller (rev 20)' on my machine
$ sudo ./gen_restore_pciconf.sh 0000:00:1f.3
setpci -s 0000:00:1f.3 00=86 01=80 02=c8 03=a0 04=06 05=04 06=10 07=00 08=20 09=00 0a=01 0b=04 0c=10 0d=20 0e=00 0f=00
setpci -s 0000:00:1f.3 10=04 11=00 12=2d 13=3f 14=60 15=00 16=00 17=00 18=00 19=00 1a=00 1b=00 1c=00 1d=00 1e=00 1f=00
setpci -s 0000:00:1f.3 20=04 21=00 22=00 23=3f 24=60 25=00 26=00 27=00 28=00 29=00 2a=00 2b=00 2c=43 2d=10 2e=22 2f=1a
setpci -s 0000:00:1f.3 30=00 31=00 32=00 33=00 34=50 35=00 36=00 37=00 38=00 39=00 3a=00 3b=00 3c=ff 3d=01 3e=00 3f=00
setpci -s 0000:00:1f.3 40=00 41=00 42=00 43=00 44=10 45=00 46=00 47=00 48=ff 49=09 4a=fb 4b=00 4c=00 4d=00 4e=00 4f=00
setpci -s 0000:00:1f.3 50=01 51=80 52=43 53=c0 54=0b 55=01 56=00 57=00 58=00 59=00 5a=00 5b=00 5c=00 5d=00 5e=00 5f=00
setpci -s 0000:00:1f.3 60=05 61=00 62=81 63=00 64=18 65=0b 66=e0 67=fe 68=00 69=00 6a=00 6b=00 6c=00 6d=00 6e=00 6f=00
setpci -s 0000:00:1f.3 70=10 71=00 72=91 73=00 74=00 75=00 76=00 77=10 78=00 79=28 7a=10 7b=00 7c=00 7d=00 7e=00 7f=00
setpci -s 0000:00:1f.3 80=09 81=60 82=14 83=f0 84=10 85=00 86=40 87=01 88=00 89=00 8a=00 8b=00 8c=a1 8d=04 8e=01 8f=00
setpci -s 0000:00:1f.3 90=00 91=08 92=28 93=00 94=00 95=00 96=00 97=00 98=00 99=00 9a=00 9b=00 9c=00 9d=00 9e=00 9f=00
setpci -s 0000:00:1f.3 a0=00 a1=00 a2=00 a3=00 a4=00 a5=00 a6=00 a7=00 a8=00 a9=00 aa=00 ab=00 ac=00 ad=00 ae=00 af=00
setpci -s 0000:00:1f.3 b0=00 b1=00 b2=00 b3=00 b4=00 b5=00 b6=00 b7=00 b8=00 b9=00 ba=00 bb=00 bc=00 bd=00 be=00 bf=00
setpci -s 0000:00:1f.3 c0=02 c1=06 c2=02 c3=28 c4=00 c5=60 c6=80 c7=04 c8=00 c9=0c ca=a5 cb=82 cc=10 cd=00 ce=03 cf=00
setpci -s 0000:00:1f.3 d0=00 d1=0c d2=b5 d3=02 d4=10 d5=00 d6=03 d7=00 d8=00 d9=00 da=00 db=00 dc=00 dd=00 de=00 df=00
setpci -s 0000:00:1f.3 e0=00 e1=00 e2=00 e3=00 e4=00 e5=00 e6=00 e7=00 e8=00 e9=00 ea=00 eb=00 ec=00 ed=00 ee=00 ef=00
setpci -s 0000:00:1f.3 f0=00 f1=00 f2=00 f3=00 f4=00 f5=00 f6=00 f7=00 f8=b5 f9=0f fa=21 fb=01 fc=00 fd=00 fe=00 ff=00

UNIX 98 pseudoterminals briefly explained

Quite some time ago, I was experimenting with UNIX 98 pseudoterminals. A pseudoterminal is a device (or more specifically, a device pair) that has the same semantics as a regular TTY terminal except that its other end is connected to a process. The device that offers TTY semantics is refered to as the pseudoterminal slave, while the other end is known as the master. In other words, a pseudoterminal can be used to communicate two processes where one of them sees the channel as a TTY. For more information, see pts(4). This is especially useful, e.g. to implement a terminal emulator or a remote login program.

In short, issuing open() on the /dev/ptmx device (PseudoTerminal MultipleXor) results in the creation of a new master-slave device pair. The file descriptor returned by open() refers to the pseudoterminal master; the path to the matching slave end can be obtained via ptsname(). grantpt() should be called before trying to open the slave side in order to set the mode and owner of the device.

Fair enough. I thought that a good exercise would be to combine this with a TCP/IPv4 socket, forwarding traffic between the pseudoterminal master and the socket. In the gist below, select() is also used to wait for incoming data on both ends and two extra pipes + splice() are used to perform zero-copy transfers.