Egregoros

Signal feed

David Chisnall (*Now with 50% more sarcasm!*)

@david_chisnall@infosec.exchange

I am Director of System Architecture at SCI Semiconductor and a Visiting Researcher at the University of Cambridge Computer Laboratory. I remain actively involved in the #CHERI project, where I led the early language / compiler strand of the research, and am the maintainer of the #CHERIoT Platform.

I was on the FreeBSD Core Team for two terms, have been an LLVM developer since 2008, am the author of the GNUstep Objective-C runtime (libobjc2 and associated clang support), and am responsible for libcxxrt and the BSD-licensed device tree compiler.

Opinions expressed by me are not necessarily opinions. In all probability they are random ramblings and should be ignored. Failure to ignore may result in severe boredom and / or confusion. Shake well before opening. Keep refrigerated.

Warning: May contain greater than the recommended daily allowance of sarcasm.

No license, implied or explicit, is granted to use any of my posts for training AI models.

Posts

Latest notes

@lain @soatok @inex

That's not uncommon in C. The Java Native Interface has a design rationale document that says that it doesn't, for example, check null pointers because it's impossible to check for the general case of invalid pointers.

I don't really agree with this philosophy, but it did provide a nice showcase for CHERI (the JNI was explicitly designed to not be a trust boundary, so being able to turn it into a defensible one was great).

Is there any way in #FreeBSD of adding extra REQUIRES lines to RC scripts without modifying the script? I have an iscsi export that is exported over WireGuard. The iscsi scripts start after the network is up, but not after WireGuard starts. And so they try to bind go an IP that doesn't yet exist and fail (similar problems on the client and server, with different failure modes) and require manual prodding. I really want a thing in rc.conf or similar to be something like iscsid_extra_requires="wireguard" or similar.

@iodomi I've been using FreeBSD on servers since FreeBSD 4.something. It... just works. I've got a couple of machines that were upgraded in place from 9 to 14 (9 was release in 2012, 14 is still supported). The base system config has barely changed in that time.

All third-party things (i.e. the things that the server exists to run) are all updated regularly and available in packages.

Podman is somewhat immature, but mostly works for container things. There are things like @BastilleBSD for managing jails, but they have largely missed the benefits of modern container orchestration and it feels more like just managing a bunch of machines.

@iodomi The nice thing I've found about FreeBSD is that I only need to learn new stuff when I want to do something new.

Moving from from-source builds of packages required me to learn to use pkg, but the old way still works. Using ZFS for snapshots and backups meant learning some new things, but UFS and GEOM are still there if I don't want to (or I can use the minimal feature set of ZFS and pretend it's UFS).

The way that I learned to configure the network 20+ years ago is still the way I configure a network. I learned a few new things for IPv6 autoconfiguration. The firewall rules I wrote in pf back then still work. Along the way, pf grew some new features and I need to learn something if I want to use them, but if I don't, things remain the same.

I know people like to make fun of niche operating systems, but for the five years I was at Microsoft I used Windows (10 then 11) as my daily driver. It’s much less stable than a professional OS, but it does kind-of work. I wouldn’t say it’s ready for the desktop. The UI is inconsistent and changes randomly between releases, a load of common software is basically useable only in a VM, it lags and freezes periodically (unlike an OS designed for interactive use, random drivers run a load of things directly in interrupt handlers, so you get latency spikes that you wouldn’t see in a more mainstream desktop OS) and the update process can hose the system, so it’s mostly of interest to people who like tinkering with their machines than people who actually want to get work done. Oh and a load of random bits of the OS have ads, but that’s what you get from a free ad-supported system instead of one developed by an active open-source community.

I don’t think I’d recommend anyone use it as their daily driver or in a work setting, but it’s not totally unusable. It’s not at the level of maturity than you’d expect from, say, Linux or FreeBSD, especially not for client workloads. If you do have to use it, I recommend that you install FreeBSD in a Hyper-V VM for real work. That’s what I did and it works quite well.

@feld @paco

The Morello cluster we set up at MS was exposed for GitHub Actions runners. We forwarded the GitHub web hook thing to an Azure message queue thing that the head node read. When it received one, it used an exciting pile of expect scripts to talk to the serial console on a node to boot one of the machines. The node then booted with a read-only NFS mount as the root filesystem, generated a random key, and used that for a GELI-encryped read-write filesystem on the (200GB) local SSD. The GitHub Actions runner (actually, the portable Go rewrite) then pulled the job to run. At the end, we rebooted the node and the next job would get a new key for disk encryption.

If a job left any important data on a node, the next user would get the encrypted data and, unless they deleted the GELI layer, would get it decrypted with a different key. We didn't need to bother scrubbing anything between uses.

@paco Encrypted in transit and at rest is a baseline for cloud providers. It’s a necessary layer for any multitenancy offering to allow customers to build useful security on top (some argue that encrypted in use is also necessary). If that’s what they’re saying, that’s the same as saying ‘we use Azure and don’t configure any of the more expensive security options or build anything on top of that’.

@paco

If you move storage between tenants, you must clear it to prevent information leakage. Modern storage is quite hard to reliably erase and firmware bugs may make it possible to accidentally expose old versions. If you encrypt with a key that is at least unique to the tenant then anyone who tries to exploit this kind of thing gets data that looks random. In many cases, the encryption layer is hard to bypass, so you get some bytes that are encrypted with one AES key and decrypted with another, which is indistinguishable from random.