I am pleased to announce that sevctl will be available in the Fedora repositories starting with Fedora 34. Fedora is the first distribution to include sevctl in its repositories 🎉.
sevctl is an administrative utility for managing the AMD Secure Encrypted Virtualization (SEV) platform, which is available on AMD’s EPYC processors. It makes many routine AMD SEV tasks quite easy, such as:
Generating, exporting, and verifying a certificate chain Displaying information about the SEV platform Resetting the platform’s persistent state As of this writing, Fedora 34 is entering its final freeze, but sevctl is queued for inclusion once Fedora 34 thaws.
Do you ever get frustrated with waiting for a heavy VM image to download or with installing operating systems onto virtual machines manually? It can start to feel cumbersome after a while, especially if you bring up and tear down lots of virtual machines as part of your workflow. It’d be nice if spawning a ready-to-use VM was as quick and as easy as it is when using a public cloud.
Don’t you love it when your compiler thinks hard so you don’t have to? Rust’s built-in static analysis is praised for providing all kinds of safety guarantees for your code. Today, it’s not about your code, or even my code; it’s about how calling Linux ioctls through a type-safe abstraction layer exposed a bug in an ioctl definition and Rust’s type-checker was the first one to bark about it!
iocuddle is a library for improving the safety of ioctl calls from Rust.
Hacktoberfest 2020 had a rocky start. I’m not here to argue against any of the criticisms brought up by other members of the community. Their feedback is not unfounded. However, I don’t believe it was all bad.
I signed one of my weekend projects up for Hacktoberfest to gain some more experience in a maintainer role rather than an individual contributor role. In this regard, I believe Hacktoberfest 2020 was a successful experience for myself and for the contributors who spent their time and energy submitting patches to my project.
A while back, I participated in a software engineering capstone with a group of other computer science students to complete my degree. Our project was to create a from-scratch implementation of grsecurity’s “randstruct” GCC plugin for the Clang compiler. Long story short, we ended up sending out a request for comments (RFC) on the initial draft that we produced during the capstone. A number of Clang/LLVM contributors took the time to review what we made and kindly suggested some changes for a future revision.
Have you ever wondered how Linux knows what PCI devices are plugged in? How does Linux know what driver to associate with the device when it detects it?
In short, here’s what happens:
During the kernel’s init process (init/main.c), various subsystems are brought up according to their “init levels.” Among these early subsystems are the ACPI subsystem and the PCI bus driver. The ACPI subsystem probes the system bus. This “probe” is actually a recursive scan since there can be other devices that act as “bridges” from that main system bus.
It is sometimes hard to see past the thick haze of caution surrounding the use of C Preprocessor macros in your code. Indeed, the dangers of Macromancy are well-stated in many corners of the internet. You would do well to heed them.
However, there are times where a judicious use of macros can help reduce duplication in your code and make it tidier and easier to reason with. Every time a block of code is duplicated by hand, it is likely to become yet another maintenance burden to contend with.