HackerLangs
TopNewTrendsCommentsPastAskShowJobs

fweimer

1,757 karmajoined 4 ปีที่แล้ว

comments

fweimer
·5 วันที่ผ่านมา·discuss
It's still bad for emergency services if everyone does it on the same day.
fweimer
·7 วันที่ผ่านมา·discuss
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.
fweimer
·7 วันที่ผ่านมา·discuss
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.
fweimer
·7 วันที่ผ่านมา·discuss
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.
fweimer
·7 วันที่ผ่านมา·discuss
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.
fweimer
·11 วันที่ผ่านมา·discuss
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?
fweimer
·18 วันที่ผ่านมา·discuss
Everything we need is already upstream. I think the changes were:

    commit 0690dc39644d15fc89813419ffcdf9754b098260
    Author: Mark Wielaard <[email protected]>
    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 <[email protected]>
    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
fweimer
·18 วันที่ผ่านมา·discuss
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).
fweimer
·20 วันที่ผ่านมา·discuss
Using __builtin_unreachable in this way makes the switch version unsafe, too.
fweimer
·25 วันที่ผ่านมา·discuss
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.
fweimer
·26 วันที่ผ่านมา·discuss
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.
fweimer
·เดือนที่แล้ว·discuss
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.
fweimer
·เดือนที่แล้ว·discuss
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.
fweimer
·เดือนที่แล้ว·discuss
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.
fweimer
·เดือนที่แล้ว·discuss
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.
fweimer
·เดือนที่แล้ว·discuss
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.
fweimer
·เดือนที่แล้ว·discuss
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.
fweimer
·เดือนที่แล้ว·discuss
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.
fweimer
·เดือนที่แล้ว·discuss
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.
fweimer
·2 เดือนที่ผ่านมา·discuss
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.