Archive for August 2, 2024

Friday, August 2, 2024

Securing Virtual Machines on Apple Silicon

Howard Oakley:

In addition to Sequoia VMs on Apple silicon Macs being able to use services such as iCloud using Apple ID, they now appear able to support full-strength FileVault when Apple ID is activated. This contrasts with FileVault supported by previous macOS guests, which appears comparable to that provided by Intel Macs without T2 chips, or on external disks of any Mac, in that the Secure Enclave isn’t involved in protecting their encryption keys, as explained in Apple’s Platform Security Guide. Thus an attacker who has access to an older VM could copy that and attempt to gain access by brute force.

[…]

The best that a VM has been able to offer before Sequoia is relative privacy, but little more protection than already available on the host’s internal SSD. That assumes you store your VMs on the internal Data volume, which isn’t good practice in terms of snapshots and backups, as those will be significantly larger as a result. Storing VMs externally benefits from encrypted APFS, but that’s not as robust as full-strength FileVault.

If you want to set up a private VM using lightweight virtualisation on Apple silicon[…]

Previously:

Unread RSS Reader for Mac

John Brayton:

Unread for Mac is a native Mac app. The user interface is built with AppKit and a touch of SwiftUI.

[…]

Like on iPhone and iPad, on Mac you can easily switch between showing feed text, webpage text, or both for an individual article.

The latter is for feeds that contain only a summary.

Unread is a free app. Premium features are available with a subscription.

The subscription is $4.99/month or $29.99/year. An interesting feature is “Save to Unread,” which lets you add random (non-feed) pages from your Web browser to read in the app.

It’s not AppleScriptable, so it can’t work with EagleFiler’s capture key, but it does work the share extension so that you can save articles after reading them.

See also: Niléane Dorffer.

Previously:

The Switch From File Paths to URLs

Quinn:

I don’t think we ever documented this officially, but to understand this choice you have to look at the history of macOS. Traditional Mac OS did not use paths a lot. Rather, files were identified by an FSSpec, which contains a volume identifier, a directory ID, and a name. The directory ID was an HFS [Plus] catalogue node ID (CNID), which is kinda like an inode number.

Additionally, starting with System 7 it was possible to track a file with a volume identifier and the file ID, that is, the CNID of the file itself.

This was quite tricky to support on a Unix-y platform like Mac OS X. At the lowest levels of the system you needed the ability to manipulate files based on CNIDs rather than paths. For an explanation of how this was done, see QA1113 The “/.vol” directory and “volfs” (note, however, that volfs is no longer a thing and the same functionality is now implemented in a very different way).

[…]

So far, so much obscure backward compatibility. However, since we made the decision to use file URLs we’ve exploited that to significant advantage[…]

Via Matt Gallagher:

There’s a lesson about attaching data (like security attributes) to an opaque interface (like NSURL). Because my mental model of NSURL is as plain RFC-3986 storage, these attributes are easy to lose and the security behaviours are easy to forget, when moving data around an app (I wish we received a bookmark type that made this explicit).

Jim Luther:

The original proposal was not to use a NS/CFString object encapsulating the path or a NS/CFURL object, and instead use a new object type to identify a file’s location, to cache properties, etc. That idea was vetoed in early API reviews because there were already API that took file locations as paths or URLs. We were told to pick path or URL. We chose URL objects over string objects.

I still think a new object type would have been cleaner and better in the long run. 🤷‍♂️

[…]

FSRefs were not objects so they didn’t fit into the Cocoa (or CoreFoundation)API memory model. They were also a fixed size glob of memory so expanding their functionality was very difficult. One of the things I did in my last year at Apple was to make the old Carbon File Manager work well with APFS and its 64-bit inode numbers. That meant making shoehorning 64-bit file and folder ids into FSRefs and translating them to 32-bit ids for the old File Manager API. Fun hacking 😀

Previously:

Update (2024-11-25): Uli Kusterer:

I’m still kinda confused (NS)Stream was so late to arrive and has so little support for serializing objects. I guess PowerPlant spoiled me.

I was and remain surprised that the stream APIs are comparatively awkward and rarely used throughout Apple’s frameworks.

Jim Luther:

How bad was the URL performance? Using the new “efficient” Snow Leopard URL file system property API: getattrlist (the Apple extended lstat function that gets more file system data) was only around 5% of the time. Caching that data in newly created CF/Cocoa objects and returning those objects was another 25% of the time. The rest of the time was spent creating the URL from the file system path and getting the file system path back from the URL.

After fixing the URL performance issues, Apple found lots of other things to change that helped the performance of those API, and thus other parts of the system: like tagged pointers (file system properties are mostly numbers), and optimizing all-ASCII CF/NSStrings (like URL strings).

Better performance tools really helped us easily determine what was causing performance issues.

Until Lion or maybe Mountain Lion, the new “efficient” URL file system API was a lot slower than using the old Carbon File Manager API.

Jim Luther:

Those are the two primary reasons Apple did not add a URL property to get a directory’s valence (like was available in the deprecated Carbon File Manager API).

Snapshots Aren’t Backups

Howard Oakley:

What is different is that restoring a whole volume from a snapshot is a one-way trip, and there is no undo. This is because snapshots subsequent to that used to restore from will be removed, and you won’t then be able to ‘roll forward’ to a later snapshot. That contrasts with a normal backup, where items remain available from any other backup that is retained in the backup store.

[…]

Because snapshots share the same container as the current volume, and share many file extents with them, they are prone to common errors. In particular, common file extents make it more likely that faults occurring in extents and data storage will affect them both. This is particularly important as one of the most common file system errors that corrupts data in files occurs when extents for two separate files overlap. A snapshot is thus more vulnerable than a backup on a different disk, or even one in a different container on the same physical store.

[…]

Snapshots do have one specific advantage over backups when it comes to their coverage. As they include the whole file system metadata for the volume, no items present in that volume are excluded from its snapshots. If you want to restore an item that has been excluded from backups made of any volume, you can therefore do that from its latest snapshot, if that item was present in the volume at the time that was made.

The only disadvantage to this is that snapshots can be disproportionately large compared to volume backups.

Snapshots are a great tool, but they don’t replace backups. The combination can be powerful. All my clone backups are now to APFS drives that make a new snapshot for each backup. I would like to be able to restore previous versions of files or folders from a year ago or more. Every once in a while I archive a clone drive and stop updating it. But I don’t have enough drives in rotation to keep a version for each week or month. Snapshots make that possible, albeit with less redundancy. Unfortunately, Mac backup software has kind of regressed in that it no longer provides great tools for browsing and searching old versions, but at least with snapshots we can easily and efficiently store them.

Previously:

Copyright © 2000–2024 Michael Tsai.