fweimer

There are far more cases. Some ABIs use callee-saved registers for parameter-passing under certain circumstances, for example. Usually, there are compatibility restrictions on the signatures of the current and tail-called functions beyond the return type, too.

This is different from Scheme or the MLs (there as a quality-of-implementation feature) where tail calls into arbitrary functions are expected not to lead to space leaks.

It's not really about a monorepo, but how many changes you can have in flight in parallel. Desirability of merge-and-rebase-and-check depends on more factors: the rate of change, the number of developers, the time the pre-merge checks take and the reliability of those checks, and how often pre-merge checks fail (legitimately or otherwise). How conflict-prone queue changes are matters, too.

I would like to have something like this for one of the repositories I work on, which is pretty far away from being a monorepo (it's mainly producing two tightly interlinked binary objects). Fortunately, I believe Gitlab offers something like it, at least as a preview feature (under the namemerge-and-rebase or something like that).

> interfaces still can’t declare type-parameterized methods

What would an implementation look like? Wouldn't it be quite different from the existing one because it has to rely heavily on indirection because (limited) monomorphimization is not possible?

I can see it happening if people start depending AI-generated proof libraries for the work they are interested in. Not because the libraries are proprietary, but because they are impenetrable. AI usage wouldn't result in this directly, but it could be a consequence of formal verification as a substitute for canonicalization in some cases.

(Disclaimer: I had quite a bit of formal training in mathematics at one point, but have worked in software for more than two decades now. I wasn't on the applied side, but I recall that MATLAB evoked similar concerns back in the day.)

I remember enhancing the F-PC visual editor to display the checksum for the current line because I did not have access to whatever method the magazine recommended (maybe OCR with Logitech Scanman?).

Recent glibc uses the correctly rounded tanh from CORE-MATH, so it returns different values than what's quoted in the article. It's unclear today if it's possible to achieve reasonable performance for other transcendental functions with correct rounding, so other functions have their own unique fingerprints.

There's Naïve Bayes (although it's sometimes labeled in more explicit terms).

The problem with “unconventional” is that these works are anything but. As far as I can tell, the most of the paintings presented on the site follows a particular style. I don't think someone who is inspired to paint after watching the Joy of Painting would necessarily end up with something like this, so it's not just about being amateurish. It's also quite likely that some of the painters are anything but self-taught and have chosen to paint in this particular way.

It's still bad for emergency services if everyone does it on the same day.

We have plenty of functions that convert one byte array to another byte array. Both arrays have specified bounds. The functions are total (an error return indicates if the input or output arrays are incomplete). Most of them do not even have state that is preserved between calls. Complete source code is available in the same build for all the functions they call.

In theory, this should be very straightforward to prove correct with many of the current tools. In practice, no one has shown us how to do it. We could even rewrite the code from a macro/#include maze to proper function calls if that's a prerequisite for analysis. At this point, I would even take a one-off analysis.

I still have to see a single glibc bug that truly matters. I don't have illusions about our code quality, so there must be something to find.

We got many high-quality bug reports, some of them with a security aspect to them. Several of them received CVSSv3.1 scores of around 9.8 from the rating agencies, but these high numbers are misleading. (Vulnerability scoring is hard, and it's pretty much impossible for a library without reference to an application that uses the library.) Looking beyond the numbers, everything reported this year (and late in last year) was pretty harmless so far.

Does this mean LLMs are making a difference? For upstream developers, definitely. For end users? Not that much yet.

Maybe the picture changes once the organizations sitting on the good findings figure out how to disclose them to the relevant upstream projects. When I read the announcement of Project Glasswing, I immediately thought that this was going to be the hardest part.

I think it's rather this:

3. People were already sitting on vulnerability reports from their own tools and threw them over the wall.

They were worried about getting scooped. They had to consider Mythos' alleged capabilities as a tool, and Project Glasswing potentially establishing a well-run disclosure and remediation process. Both could devalue preexisting results.

I think the decode phase of inference typically uses local compute resources poorly due to the very small batch size. If you can run many inference tasks in parallel, this will make local inference more competitive to centralized inference, not less.

I think you got it backwards. Wouldn't it be way worse if they used your likeness for advertising to your friends? Compared to random people who don't know you?

Everything we need is already upstream. I think the changes were:

    commit 0690dc39644d15fc89813419ffcdf9754b098260
    Author: Mark Wielaard <mark@klomp.org>
    Date:   Sun Sep 22 23:24:34 2024 +0200
    
        Implement /proc/self/exe readlink[at] fallback in POST handler
        
        Calling the readlink[at] syscall directly from the PRE handler defeats
        the FUSE_COMPATIBLE_MAY_BLOCK (SfMayBlock) flag. Add a POST handler
        that only explicitly calls the readlink[at] handler for the
        /proc/self/exe fallback (this should be fine unless /proc is also
        implemented as fuse in this process).
        
        Adjust readlink[at] GENX_ and LINX_ syswrap macros to GENXY and LINXY.
        
        https://bugs.kde.org/show_bug.cgi?id=493507
    
    commit ddf397c024c80382f7a2f3a0d46d58fb839eef96
    Author: Mark Wielaard <mark@klomp.org>
    Date:   Sat Sep 21 22:27:24 2024 +0200
    
        Add missing FUSE_COMPATIBLE_MAY_BLOCKs
        
        Various syscalls (in particular "at" variants) PRE handlers were
        missing a FUSE_COMPATIBLE_MAY_BLOCK statement.
        
        Add it to the generic PRE handlers of access and statfs64. And the
        linux PRE handlers of mknodat, fchownat, futimesat, utimensat,
        utimensat_time64, renameat, renameat2, readlinkat, fchmodat,
        fchmodat2, faccessat and faccessat2.
        
        https://bugs.kde.org/show_bug.cgi?id=493454

There's an older effort called Typed Assembly Language (TAL) by Greg Morrisett et al. It was a rather ambitious in some ways because it tried to model inter-procedural control flow, including exceptions. They eventually had a solution for array bounds checking, but I haven't seen anything for array initialization (that doesn't depend on a memory allocator that zeros everything or multi-instruction macros with semantics defined by fiat).

Using __builtin_unreachable in this way makes the switch version unsafe, too.

I'm not convinced this is true. Otherwise, it does not bode well for Rust code because any type safety glitch will be considered a vulnerability. This would be really challenging for Rust developers because it goes beyond unsafe Rust code. You can easily have unexpected panics because your types do not enforce invariants as you expect. If a library has such a bug, is this a denial-of-service vulnerability in the library? Rather than dealing in absolutes, I would say that it's impossible to tell in isolation. If applications do not misuse the library in ways that triggers the panic, probably not, and treating this as a vulnerability just results in pointless noise.

Determining the impact of library bugs can be really hard. For example, some functionality might be so broken that it's simply impossible to use correctly, so a buffer overflow on top does not make a difference. Or a buffer overflow vulnerability triggers consistently during system boot, so that you never get to the login prompt. These can hardly be considered vulnerabilities. On the other hand, we have clear buffer management bugs, where we must expect that there is application code out there which specifies tight buffer bounds and requires that the library stays within that buffer. (Rust should help here, at least out-of-bounds accesses should turn into panics.) But most bugs are unfortunately somewhere in the middle. Tools like Debian Code Search can provide some evidence. But in the end, it's more subjective than I'd like it to be.

On the extreme end, we have compiler soundness bugs. I'm a bit of worried that I'm hitting any of those when I'm tweaking the types until the compiler no longer complains. Beyond the basics, I really don't have a grasp of Rust's type system rules. But I suspect they very difficult to hit by accident, and even if I do, the code must be miscompiled in meaningful, but difficult-to-notice way. All that seems rather unlikely, which is why these bugs aren't treated as vulnerabilities.

I really think we need some corrective factor (such as potential implication impact) when determining whether toolchain bugs are vulnerabilities.

The glibc test suite contains a few tiny FUSE file systems. For example, there is one that just happens to contain every file that mkstemp attempts to create, for a test that exercises the O_CREAT|O_EXCL failure path. Like the Rust fuser crate, it uses the kernel API directly. The tests are slightly brittle because sometimes we encounter a new LSM that triggers unexpected file system operations, but it's not too bad overall.

What I found funny when I discovered it is that you can create a thread in the same process that provides the FUSE file system implementation for this very process. It makes it much easier to write certain tests, especially debugging. We had to teach valgrind that more system calls effectively perform callbacks into the same process, but fortunately valgrind already had a FUSE_COMPATIBLE_MAY_BLOCK mechanism for that.

You can try to execute POPCNT. If it does not fault, its presence is only hidden via CPUID.

Live migration support may be the reason why they stick to the baseline. That's most likely to be migratable across different CPU types. Although with a bit of effort, you can figure out what is support by your fleet and configure that into the hypervisors.

I'm skeptical that pre-SSE-4.2 etc. CPUs are economically viable for running customer workloads due to electricity costs.

It's likely this is a hypervisor misconfiguration. Either way, one has to wonder what kind of mitigations for cross-tenant leakage they are missing.

POPCNT is an interesting example. Runtime dispatch (with a conditional branch) would actually make sense for it because it's comparatively difficult to implement from scratch. PDEP and PEXT might be similar (but I don't think compilers pattern-match for it, unlike POPCNT). AArch64 uses localized run-time dispatch extensively because LL/SC atomics are so very bad on current cores, but there isn't anything comparable in the x86-64 space (POPCNT isn't that frequent).

For many other things, like using a YMM register to copy a 32-byte struct or a variable shift, run-time dispatch just not make sense. You will only see a benefit if you generate this code unconditionally. For FMA, you wouldn't even get bit-identical output, leading to testing concerns.

Newer (relatively speaking) x86-64 instruction sets support many three-operand instructions, which are actually easier to use for compilers than instructions with overwritten source operands or hard register constraints. Pattern matching for instructions that do not have a direct C representation (such as NAND) is also pretty standard in compilers. Auto-vectorization is more tricky (especially when you want code to actually run faster …), but some of the new ISAs are impactful without it. And of course there are expanders for fixed-size memcpy and memset that can use wider vector instructions quite easily. Those operations are quite common.

Do SAT scores measure anything about pedagogic aptitude? I expect that at best, you get some form of correlation (in which direction?).

For teachers, other things matter more than reasoning skills or subject matter knowledge, especially in rural or otherwise challenging communities.

Over here, it's common that consumers don't have a direct relationship with the card company. I'm not sure if they would even be able to identify me.

The article mentions Stripe's product in this space: https://stripe.com/en-us/radar

There are similar offerings from other companies. I don't know if bundling this with payment processing is common.

U.S. chargeback rules are different. In other countries, you cannot repudiate credit card transactions that you authorized (and this applies to Mastercard/Visa, too). You need to do something else if you end up in a dispute with the merchant.

I see. I assumed that given they were flying at 37,000ft, they would have more time to react. But the BEA report says that after autopilot disconnection, only two minutes passed until they reached this situation:

> Only an extremely purposeful crew with a good comprehension of the situation could have carried out a manoeuvre that would have made it possible to perhaps recover control of the aeroplane. In fact, the crew had almost completely lost control of the situation.

I had no idea that things could go wrong so quickly, even at that altitude.

Surely you need an alternative to Box<dyn Error> for reporting memory allocation failures?!

It's confusing because this statement predates the release of Panther Lake and Amston Lake. Neither support AVX10.

I'm excited about Nova Lake as well. Maybe not so much for the EGPRs (maybe we should have made 4 of the new registers callee-saved?), but there are other goodies as well.

Historically, the edge business unit did a bit of their own thing with their CPUs. I believe the transition is finally happening once we see AVX10 CPUs over there as well. Until then I'm somewhat skeptical. (To be clear, I have no insight into their roadmaps, precisely because it's so separate.)