Woodruff: Weird architectures weren't supported to begin with

Posted Mar 1, 2021 22:13 UTC (Mon) by pizza (subscriber, #46)
In reply to: Woodruff: Weird architectures weren't supported to begin with by rodgerd
Parent article: Woodruff: Weird architectures weren't supported to begin with

> that these architectures have been providing security theatre by purporting to run software that just compiles, maybe runs semi-reliably, and certainly has no particular guarantee that it actually runs as intended.

Uh.... can't the same be said for pretty much every other architecture? (Or indeed, for anything other than the specific system that the upstream CI system used to run their tests, if any?)

Woodruff: Weird architectures weren't supported to begin with

Posted Mar 1, 2021 22:22 UTC (Mon) by mathstuf (subscriber, #69389) [Link] (3 responses)

Basically, yes. Folks have been asking us to provide Python wheels for Linux/aarch64 for a while, but we have no way of testing it, so I don't want to put out an official wheel without some actual trust that it has a hope of working. Instructions for making your own wheel are available for those with the gumption to do that, but the thing is that any bug submitted is basically untestable by me.

*Especially* in a project full of C and C++ code that does low-level file I/O (especially binary), hardware interaction, or anything like that, anything not tested regularly is not trustworthy to the level people would like or even probably think it is.

Woodruff: Weird architectures weren't supported to begin with

Posted Mar 7, 2021 13:50 UTC (Sun) by nix (subscriber, #2304) [Link] (2 responses)

> Basically, yes. Folks have been asking us to provide Python wheels for Linux/aarch64 for a while, but we have no way of testing it

Um... aarch64 boxes literally cost a few quid at this point, now that a lot of the SBCs are aarch64. Surely it's easy to get a way of testing things there?

Woodruff: Weird architectures weren't supported to begin with

Posted Mar 7, 2021 15:25 UTC (Sun) by mathstuf (subscriber, #69389) [Link] (1 responses)

Our software needs OpenGL tested and generally need hefty hardware to do builds in a reasonable timeframe. We've gotten a few for other projects but we haven't gotten them for this one yet. First up is more macOS and Windows cycles since those machines already aren't keeping up.

Woodruff: Weird architectures weren't supported to begin with

Posted Mar 15, 2021 14:52 UTC (Mon) by nix (subscriber, #2304) [Link]

I'm sure you know this already, but the way one does this is to cross-build (or, since that is often difficult, build atop an ARM chroot with binfmt_misc set up to redirect things to qemu-user-arm): this works fine unless your build process requires something like extensive multithreading that qemu-user still does badly (so, 99% of build processes are fine). Then tests, and only tests, are run via ssh to an SBC which shares that chrooted filesystem with the host (and it's not as though OpenGL-capable SBCs are hard to find or costly, though if you want one with open source drivers that might be harder). This is not even slightly new in the embedded world: DejaGNU has long supported this model via its "remote board" concept.

Woodruff: Weird architectures weren't supported to begin with

Posted Mar 1, 2021 22:35 UTC (Mon) by roc (subscriber, #30627) [Link] (2 responses)

Yes. Rust at least supports several platforms as "tier 1" where tests are run and work is gated on tests passing. https://doc.rust-lang.org/nightly/rustc/platform-support....

Woodruff: Weird architectures weren't supported to begin with

Posted Mar 1, 2021 23:15 UTC (Mon) by pizza (subscriber, #46) [Link] (1 responses)

Rust isn't saying that "we support on any random x86_64 Linux system" -- instead they are saying "we test on x86_64-unknown-linux-gnu 64-bit Linux (kernel 2.6.32+, glibc 2.11+)" with the unspoken implication of "if you're not using this, you're on your own."

In other words, deviate from that very-under-specified platform definition and you'll end up in a position where Rust "just compiles, maybe runs semi-reliably, and certainly has no particular guarantee that it actually runs as intended."

Given that most Linux users get their Rust toolchain from their distribution instead of upstream, they're all in the "no particular guarantee" territory since the distro build hosts are not configured identically to the upstream rust CI systems.

Mind you, that's not a bad thing in of itself, and it affects pretty much all distributed-as-source software [1] There's no particular guarantee that it worked on anything other than the original developer's system. Heck, even that's not guaranteed, if one reads the actual license text.

If upstream supplies a test suite then that can be used to build confidence that the software will "run as intended" on relatively random systems, but otherwise, caveat emptor.

[1] Granted, Rust is unusual in that it actually does need to know about the underlying CPU architecture and operating system/syscall interface..

Woodruff: Weird architectures weren't supported to begin with

Posted Mar 1, 2021 23:45 UTC (Mon) by pizza (subscriber, #46) [Link]

Oh, I should clarify -- I'm not saying that Rust is somehow deficient here; quite the opposite! They make it very clear what they consider "supported" and provide a test suite that anyone can use to (reasonably) guarantee that things can still be expected to work if you deviate from the supported platform configurations.

This is the same situation where most F/OSS projects arguably fall; the authors only "guarantee" it works on the platforms they use for development, with some sort of test suite that is used to build confidence that can be expected to work on a relatively random system that still meets the minimum requirements.

But that doesn't somehow make compiling and using this software on relatively obsolete platforms "security theater".