The other day I created a small CLI + library written in Rust, that helps to measure the TTFB (time to first byte) for HTTP GET-Requests in Rust. I had this project on my to-do list for a few months now and finally some time for it. I got inspired by the Dev Tools in Google Chrome. You can see an example screenshot from Chrome down below: I wanted to program something similar. Read more…
In the previous blog post we talked about how to use QEMUs debugcon feature. To do this responsibly, we should only do this if the binary runs in fact inside QEMU. To find this out, one can use the cpuid instruction. It gives us a lot of information about our environment including information about the CPU brand name or if we run inside a hypervisor. This instruction is specific for the x86-platform. It Read more…
QEMU is a VMM often used for low-level OS/kernel development and testing. Especially when you write your own OS/kernel, things can get really hard and difficult to debug. Furthermore, there are not many debug capabilities, as you can’t write to files or print to the screen in early boot phases, thus, without loaded drivers. For these cases, QEMU has a featured called debugcon. It is not as good/prominent documented as it should be, Read more…
Update: In the meantime, my knowledge of Rust got better. &str simply uses the layout of a fat pointer. Original article down below. TL;DR: At least on x86_64 a &str is two u64 (16 byte) long. The first u64 is a pointer and the second u64 is the length of the string. Due to a small procrastination session, I wanted to know what the layout of &str looks like in memory (on x86_64). Read more…
Even though I’m working with Rust for over 2.5 years now, I unfortunately never made a deep dive into the async/await/future-world. But I started using tokio a few days ago and a few questions came up. Tokio is a runtime for executing futures, great! For this, tokio needs some kind of “tasks” or “lightweight userland threads”, okay. To schedule N tasks across M cores, tokio need some kind of event loop,.. so.. similar Read more…
EDK2 is a development environment to create firmware implementations that follows the UEFI specification. It is part of tianocore project. which is the reference implemenation for UEFI. Multiple “packages”, which are the sources to build tianocore for different platforms (x86, ARM, QEMU), are located inside the git repository of “EDK2”. OVMF, which stands for Open Virtual Machine Firmware, is one of these packages. It enables UEFI inside virtual machines, like in QEMU environments. Read more…