johncolanduoni

It has to be as ancient as the oldest glibc you want to support, usually a Red Hat release with very old version and manual security backports. These can have nearly decade-old glibc versions, especially if you care about extended support contracts.

You generally have difficulty actually running contemporary build tools on such a thing, so the workaround is to use —-sysroot against what is basically a chroot of the old distro, as if cross-compiling. But there are still workarounds needed if the version is old enough. Chrome has a shorter support window than some Linux binaries, but you can see the gymnastics they do to create their sysroot in some Python scripts in the chromium repo.

On Windows, you install the latest SDK and pass a target version flag when setting up the compiler environment. That’s it. macOS is similar.

Making an executable “request” older symbol versions is incredibly painful in practice. Basically every substantial piece of binary software either compiles against an ancient Debian sysroot (that has to have workarounds for the ancient part) or somehow uses a separate glibc copy from the base system (Flatpak, etc.). The first greatly complicates building the software, the second is recreating Windows’ infamous DLL hell.

Both are way more annoying than anything the platforms without symbol versioning suffer from because of its lack. I’ve never encountered anyone who has packaged binaries for both Linux and Windows (or macOS, or the BSDs) that missed anything about Linux userspace ABIs when working with another platform.

We definitely can, because almost every other POSIX libc doesn’t have symbol versioning (or MSVC-style multi-version support). It’s not like the behavior of “open” changes radically all the time, and you need to know exactly what source symbol it linked against. It’s really just an artifact of decisions from decades ago, and the cure is way worse than the disease.

Even open-source software has to deal with the moving target that is ABI and API compatibility on Linux. OpenSSL’s API versioning is a nightmare, for example, and it’s the most critical piece of software to dynamically link (and almost everything needs a crypto/SSL library).

Stable ABIs for certain critical pieces of independently-updatable software (libc, OpenSSL, etc.) is not even that big of a lift or a hard tradeoff. I’ve never run into any issues with macOS’s libc because it doesn’t version the symbol for fopen like glibc does. It just requires commitment and forethought.

I don’t know about calling them fatal, but inculcating a culture that believes the flaws are inescapable laws of reality is probably key.

Next to Newark Airport too. He’s lucky they didn’t throw the book at him - they could’ve hit him for reckless endangerment.

Where were we talking about the UK? All anyone said in this message chain was HFT (and NIST).

The victim firm would definitely notice, they’d tell the FCC, and their investigators will show up with a device that literally points them to wherever the jammer is. If you do this for stupid, silly reasons you will get fined[1], if you do it in commission of another crime you will probably get made an example of. It doesn’t matter how evil you are, it’s hilariously easy to get caught doing this.

[1]: https://www.nj.com/news/2013/08/man_fined_32000_for_blocking...

The parent was saying HFT firms would do this to other HFT firms. They would care about doing this kind of thing - it’s not a white collar crime. And foreign adversaries would care about doing this during peacetime, especially for very unclear benefit.

Deploying a GPS jammer in civilized territory is a great way to go to prison.

I don't have an issue with `unsafe` - Java has the mythical unsafe object, C# has it's own unsafe keyword, Python has ffi, etc. The title of that blog post - that there is no memory safety without thread safety - is not quite true and it acknowledges how Java, C#, and Go have strong memory safety while not forbidding races. Even the "break the language" framing seems like special pleading; I'd argue that Java permitting reading back a sheared long (64-bit) integer due to a data race does not break the language the same way writing to a totally unintended memory area or smashing the stack does, and that this distinction is useful. Java data races that cause actual exploitable vulnerabilities are very, very rare.

There are functions on many C allocators that are explicitly for non-trivial allocation scenarios, but what major operating system malloc implementation returns NULL? MSVC’s docs reserve the right to return NULL, but the actual code is not capable of doing so (because it would be a security nightmare).

I’ve used RocksDB for this kind of thing in the past with good results. It’s very thorough from a data corruption detection/rollback perspective (this is naturally much easier to get right with LSMs than B+ trees). The Rust bindings are fine.

It’s worth noting too that B+ tree databases are not a fantastic match for ZFS - they usually require extra tuning (block sizes, other stuff like how WAL commits work) to get performance comparable to XFS/ext4. LSMs on the other hand naturally fit ZFS’s CoW internals like a glove.

Somewhat unrelated, but I just looked at the RustFS docs intro[1] after seeing it here. It has this statement:

> RustFS is a high-performance, distributed object storage software developed using Rust, the world's most popular memory-safe language.

I’m actually something of a Rust booster, and have used it professionally more than once (including working on a primarily Rust codebase for a while). But it’s hard to take a project’s docs seriously when it describes Rust as “the world’s most popular memory-safe language”. Java, JavaScript, Python, even C# - these all blow it out of the water in popularity and are unambiguously memory safe. I’ve had a lot more segfaults in Rust dependencies than I have in Java dependencies (though both are minuscule in comparison to e.g. C++ dependencies).

[1]: https://docs.rustfs.com/installation/

No non-embedded libc will actually return NULL. Very, very little practical C code actually relies only on specified behavior of the spec and will work with literally any compliant C compiler on any architecture, so I don’t find this particularly concerning.

Usefully handling allocation errors is very hard to do well, since it infects literally every error handling path in your codebase. Any error handling that calls a function that might return an indirect allocation error needs to not allocate itself. Even if you have a codepath that speculatively allocates and can fallback, the process is likely so close to ruin that some other function that allocates will fail soon.

It’s almost universally more effective (not to mention easier) to keep track of your large/variable allocations proactively, and then maintain a buffer for little “normal” allocations that should have an approximate constant bound.

Your priorities do not match that of most kernel developers or most operators of network-connected Linux systems (even if we ignore Android). So I don’t think your problem is with Rust at all, you’ll need to fork Linux if you want the project to stop putting huge amounts of effort into memory safety (as it has for decades).

What number of CVEs is Rust kernel code allowed to have before we have good evidence it’s a categorical failure? Do you turn off KASLR for your Linux machines because there exist CVEs it doesn’t protect against?

Please explain how it adds to the discussion about different ways to broaden supported Rust target architectures. Because both have the word Rust in them?

That was definitely me, you got me. How did you know from my comment about a potential Alpha LLVM backend?

Even more fun is that some of those (IOMMU and ACPI version) depend on motherboard/firmware support. Inevitably there is some bargain-bin board for each processor generation that doesn’t support anything that isn’t literally required for the CPU/chipset to POST. For userspace CPU features the new x86_64-v3/v4 profiles that Clang/LLVM support are good Schelling points, but they don’t cover e.g. page table features.

Windows has specific platform requirements they spell out for each version - those are generally your best bet on x86. ARM devs have it way worse so I guess we shouldn’t complain.

I worked on a Ruby codebase that moved to Rust - I think that part is mostly cargo-culting cool things in the news to be perfectly honest. There’s type safety advantages, but if Ruby’s performance envelope was even conceivably acceptable for your use-case there are likely better options. I strongly suspect a lot of the friction between Rust and only-C/C++ developers is the product of a bunch of people coming at Rust from higher level languages parroting lines about safety, and then looking at you blankly if you ask how it handles nested pointer indirection.

But I don’t think that applies to the people actually driving the language forward, just those talking a big game on HN/Reddit.

I wonder how good a LLVM backend for these rare architectures would have to be for that to be “good enough” for the kernel team. Obviously correctness should be non-negotiable, but how important is it that the generated e.g. Alpha code is performant for somebody’s hobby?

One C bug was not taken as clear evidence that we need to abandon C and switch to Rust. Hundreds of thousands of very similar bugs, over decades, in common code patterns were. I’ve never understood how other C or C++ developers could seriously question whether Rust solves any safety problems at all. Maybe the tradeoffs aren’t worth it for a particular use case, but how could you find it unimaginable that even just enforced bounds checks would catch lots of bugs that (normal, non-verified) C would miss? Do you doubt that Python code corrupts memory a lot less because you saw a CPython CVE once?

What language do you think Graydon Hoare was spending most of this time writing while he started working of Rust as a side project? Hint: it sure wasn’t Java. Rust is not the product of some developer who has only used 2 scripting languages and had to read the definition of stack-smashing off of Wikipedia showing those C developers how to live in the future. It’s not old enough for many of the developers working on it to have only ever used Rust. It’s mostly C and C++ developers trying to build a new option for solving their same problems.

And the kernel is infamous for being picky about the C compilers it can be successfully built with - clang couldn’t build a working kernel for a long time, and it was mostly relying on subtle GCCisms.

RDMA for new AI/HPC clusters is moving toward ethernet (the keyword to look for is RoCE). Ethernet gear is so much cheaper that you can massively over-provision to make up for some of the disadvantages of asynchronous networking, and it lets your run jobs on hyperscalers (only Azure ever supported actual IB). Most HPC is not latency-sensitive enough that it needs Infiniband’s lower jitter/median, and vendors have mostly caught up on the hardware acceleration front.

The problem with that solution is that EV already showed that a two-class system of certificates that only really differ in slight UI hints is not useful. Normies never had any idea what the green bar means, and even unusually savvy users are not likely to remember whether a particular website had an EV certificate or not last time they visited.

Client-side OCSP makes it too easy to track users. OCSP stapling largely solves that (plus the latency/fail-open issues) by having the server staple a recent OCSP response to the certificate during TLS negotiation. If OCSP stapling had succeeded, the privacy issues would have mostly disappeared (you could track that a server was serving traffic for a domain, but not the users).

> No, it's literally nothing, since you can just create whatever TLS cert you want and just MITM anyway.

> What do you think you're protecting from? Passive snooping via port-mirroring?

Yes, exactly. For datacenter to datacenter traffic, passing snooping is much easier for small-time criminals to achieve than a MITM. You can do it just by having a device on the same L2 switch domain and spoofing the MAC table (MAC spoofing/port security being un- or mis-configured is typical in those environments). No need to compromise routing at all.

> How do I establish trust with Google? How do they establish trust with me: I mean, we're not using the system designed for it, so clearly it's not possible- otherwise they would have enabled this option at the minimum.

Establishing trust with Google specifically is super-simple: their SMTP servers all have valid public PKI certificates and have for a long time. Even if they didn’t, they could give you an internal CA root to verify them. This doesn’t scale to lots of orgs, but almost all legitimate email traffic is between Google, Microsoft, Yahoo, and the top 10 marketing/transactional email services.

That’s why nobody was in a rush to solve the SMTP MITM problem. Plus, since SMTP for delivery is not authenticated at the application level, you only have to really worry about snooping/preventing delivery. If you want to send fake emails, the certificates provided by the server are irrelevant - there’s no password that you need to steal.

Even if the extension isn’t malicious, it creates a new attack vector that can affect users. If whatever URL the script is remotely loaded from is compromised, now all users of that extension are vulnerable.

Most browser extensions don’t need to insert script tags that point to arbitrary URLs on the internet. You can inject scripts that are bundled with the extension (you don’t even need to use an actual script tag). This is one part of manifest v3 that I think was actually a good change - ad blockers don’t do this so I don’t think Google had an ulterior motive for this particular limitation.