The Canadian government froze the bank accounts of truckers involved in a protest [1] [2] [3].
If a government is willing to go after the property of its own citizens without due process, foreign investors have to think: "What's to stop the same from happening to me?" Even if that foreign investor's a central bank.
[2] Maybe the truckers' protest went too far; they were blocking roads. The point isn't whether they deserved to be punished; the point is that their accounts were frozen without going through the laws and court system.
[3] This was in 2022, so it has nothing to do with the current US administration.
For anyone curious, this is hyperbole that people of certain political persuasions love to mischaracterise.
These were not "protests", they were a sustained attempt to appeal to the wrong level of government for policies of a foreign government by a bunch of people who were riled up on the internet. Highlights included nazi flags, guns, harassing and threatening women and local residents, etc.
what is most telling is that when you search for commentary about the Canadian federal government freezing bank accounts, a significant portion of links are from reactionary, right wing websites.
They did freeze bank accounts though, and in other countries with democracy, citizens are allowed to protest, “occupy” and nazi flags are free speech. Mentioning guns is hyperbole, zero protesters shot anyone. Now, the government DID take peoples rights away and their bank accounts . Very important.
Why is "occupy" in quotes? The trucks jammed downtown Ottawa and were making a tremendous amount of noise. That isn't some peaceful protest that got a permit ahead of time, it was an attempt to shutdown the nation's capital.
So...what happens to the money in the account? AFAIK normally when your account is closed, your bank gives you a cashier's check which you can use to open an account at another bank. But given that they're in OFAC, what if no other bank will have them?
Does someone who works for A/I have to drive to Italy and pick up a briefcase full of cash? Or does the money stay in the bank, inaccessible to A/I, until A/I proves they aren't terrorists? Which could be...forever, since it's basically impossible to improve you're not a terrorist once you're formally included on The Big List Of Terrorists? How do you hire a lawyer to argue your case if the money you would use to pay them has already been taken away?
Great question! Here's the answer: an entity on the SDN (Specially Designated Nationals) List, basically has all financial operations withdrawing or moving funds out of an account denied. There is no "closing" allowed. Those assets are, for all intents and purposes, frozen.
Except... Deposits still go through! It is intentional to the design that all operations around taking in money be left enabled. Also, it is strictly forbidden to inform someone that the reason for the declining of outgoing transactions is because one is on the SDN.
In short, the goal of imposing sanctions is to lock down the maximum assets possible of a sanctioned entity within the influence of the U.S. financial system.
Your observations about the problematic nature of OFAC are quite astute. You are added at the whims of the Executive Branch of the U.S. government. They won't go out of their way to tell you you are on it, and they don't let anyone else tell you either. There is in theory a process to petition to get off it, but gooooood luck with that.
A complex application process is basically a proof-of-human-work to rate-limit processing costs (for all applications, successful or not) and benefits cost (for successful applications).
In 2026, you can ask an LLM to fill out the application, reducing the expensive proof-of-human-work to a free or cheap machine proof-of-work.
I can immediately think of three different user stories for LLM-generated applications for, without loss of generality, government benefits:
- Alice is honest and likely eligible but didn't apply because the application process was too time-consuming / complex. With LLM assistance, Alice can now complete the process.
- Bob is honest and likely ineligible but didn't apply because he realized he's probably not eligible. With LLM assistance, Bob can now apply anyway -- "Throw spaghetti at the wall and see what sticks."
- Eve is dishonest and ineligible. Eve wants to make money by lying on her application to defraud the government into paying her benefits. With LLM assistance, Eve can more easily make more convincing applications to more agencies.
An interesting question that doesn't seem to be addressed by the paper is how much of the cost is driven by Alice vs. Bob vs. Eve. We can tell very different stories depending on which is the case:
- Mostly Alice: Our current taxes / budget / etc. can only pay for half of what it would cost to pay everyone entitled to benefits under the law. We quietly disenfranchise citizens of their legal right to receive benefits with a bureaucratic process that half of eligible applicants can't complete, but whoops! now a lot more people can complete it with LLM assistance and we're approving most of them because they're legitimately completing the application process and legitimately entitled to benefits. Financially it's killing us to pay what the government promised to all those people to whom it was promised.
- Mostly Bob: A lot more people are applying because LLM's make it super easy for anyone to apply. We don't approve many more applications than we did before -- but each year has about 1,000,000 more applications and 990,000 more denials than the previous year for three years running. Financially it's killing us to pay the processing costs for all those unsuccessful applications.
- Mostly Eve: We're seeing an uptick in applications that are immediately denied, or approved but later revoked, because of fraud. LLM's are making it easier for criminals to defraud the government. Financially it's killing us because we pay those fraudulent benefits before we know they're fraudulent; recovery of funds is slow and uncertain once the fraud is discovered; and fraud imposes additional costs of investigation, prosecution, and punishment.
"Bosom peril" sounds like what someone in the 1800s would write in a spicy novel describing a character's experience being unable to breathe while being hugged by a well-endowed lady.
Who else remembers the flamewars of the 90s between all the different factions of Asm programmers? MASM vs TASM vs RosAsm vs HLA (basically no one took GAS seriously at all)... it was in some ways quite similar to the Chrysler vs Ford vs GM wars.
I remember during the DOS era TASM was all the rage; it was wicked fast. Unfortunately didn't get an opportunity to do much assembly programming after moving to Windows/Unix.
When Randall Hyde published his HLA (https://en.wikipedia.org/wiki/High_Level_Assembly) i remember thinking it was a good idea since it allowed many high-level language programmers to easily learn assembly programming as it included all the well-known higher-level programming constructs. It was a proper new language, but the assembly purists were all outraged and Hyde caught a lot of flak which i think was unjustified.
The Linux kernel prefers GAS (or clang) w/ the C preprocessor. Luckily most of clang's assembler unit tests (and LLVM's MC layer unit tests) also use GAS style syntax.
Because the Intel syntax is limited, and pretty broken by binutils. I had to change my C compiler rcc to emit AT&T GAS, instead of Intel syntax, even if Intel syntax looks easier on the eye.
GNU Assembler (GAS) ≥2.45 on x86-64: call and jmp to global labels in Intel syntax cause operand type mismatch errors. RCC emits .intel_syntax noprefix by default, but GAS ≥2.45 rejects direct branches to global symbols in this mode. Local labels (.L.xxx) work fine. Tests with user-defined function calls (bitops-1, fprintf-1, etc.) may fail to assemble under these versions. Root cause: rcc emits lea r11, [rip + sI] but GAS requires AT&T sI(%rip) for globals.
This is technical writing for kernel developers who already know how memory management works. If you want to understand it better, you should study up on the x86 MMU and the kernel memory management subsystem. I'm not a kernel expert but I found it pretty understandable, so I'll try to explain it.
MMU: The memory management unit, part of the CPU designed to allow an OS kernel to flexibly control how memory addresses used by a program map to physical RAM.
Page: A 4k region of memory addresses.
Anonymous: The page is just regular old memory used by a single process for general purposes, it's not part of e.g. a memory-mapped file.
Backing: The memory corresponding to a page. The kernel can direct the MMU to map any page to any part of RAM, or delete the mapping entirely.
Zero page: The kernel keeps a single 4 KB page filled with zeros (the "zero page").
Page fault: An error that occurs when you try to write a page that's not present, or write to a read-only page. Some page faults are normal and expected by the kernel, they support features like swapping, memory-mapped files, etc. Such "expected" page faults are invisible to your program. (On the other hand, an unexpected page fault occurs when your program just straight-up accesses an address it's not supposed to, which will end your program with a SIGSEGV signal -- an all-too-familiar experience for a C programmer.)
When you allocate say 4 MB of memory, the kernel simply sets it to 1k read-only copies of the 4 KB zero page. Then when your program tries to write to a page, it faults. The kernel handles this expected fault by assigning that page an individualized memory region. If a program allocates a lot of memory, it's only assigned memory for what it actually uses, when it first uses it. This is an optimization: Every program that allocates more memory than it needs is wasteful, but the kernel can recover that waste by not backing the allocation with memory -- the program has to prove each page is needed by writing to it.
Store to a freshly-faulted anonymous page: The program stored data to its own memory, which caused an expected page fault.
> becomes invisible to that same thread's reload ~10 instructions later
The thread fairly quickly tried to read the data from the same place in memory it had just written to. It doesn't get the same data back. This is a major problem that causes the program to malfunction and crash.
> A pagemap read at the instant of the fault shows the backing is the kernel's zero page
The expected fault occurred because the program tried to write to an address that was mapped to the zero page, probably because it's the first write to freshly allocated memory. (This rules out other reasons it might be faulted, e.g. the page had been swapped to disk.)
> concurrent munmap's TLB shootdown
The page table is big and slow so the CPU caches parts of it in an area called the TLB (translation lookaside buffer). munmap is a kernel function that removes the backing for an address region. Since munmap changes the mapping, it has to inform the MMU the relevant part of the TLB is no longer valid.
> per-VMA-lock anonymous-fault fast path
This is what the kernel does when the program first writes to a zero page. Saying it's the "fast path" implies there's some (slow) special case handling in the kernel code, but the bug doesn't trigger any of the special cases, we're in the most common case, which the kernel code tries to handle as quickly as possible because it has measurable impact on performance. I would guess per-VMA-lock has to do with how the kernel synchronizes this code (a "lock" is a basic synchronization primitive, you should be familiar with it if you do any kind of multithreaded programming).
> The mechanism localizes to the interaction between the per-VMA-lock anonymous-fault fast path and a concurrent munmap's TLB shootdown. A source-level review of Linux 7.0.12 identifies a specific race in that interaction
The mechanism: What's actually happening to cause the program not to be able to load data it just stored in memory.
Localizes: The cause of a problem like this is a needle in a haystack -- it could be caused by the program, the kernel or the hardware. The analysis has narrowed down the haystack to a specific part of the kernel code.
Race in that interaction: Two parts of the kernel code, (1) The kernel code for munmap and (2) the kernel code to handle a program's first write to the read-only zero page for a fresh allocation. These two parts work fine individually but the problem occurs when they both try to change the page tables / TLB at exactly the same time. This is quite a small, specific haystack compared to "somewhere in the program, kernel or hardware" we started with.
OP here. Thank you so much for taking the time to write it!
This is so much easier to understand, and I also learnt a few things along the way, like the zero page mechanism, munmap having to notify the MMU about the invalid TLB and more.
Jeff Bezos is probably calling everyone he knows in Washington right now. The big question is, does he say "End this war immediately to stop them from bombing my datacenters" or "Escalate this war immediately to get revenge for them bombing my datacenters"?
It's obvious to me that writing "Give me a confidence score from 1-5" in your prompt will have disappointing results if you use that score directly. If you want self-reported confidence scores that are at all useful, you need to think about statistics and score calibration regardless of whether those scores are produced by an LLM or a human.
Take a corpus of problems you know the answers to, but the AI sometimes gets wrong [1]. Have the AI try to solve each problem and give you a 1-5 integer confidence score. The known proportion of correct answers in each bucket gives you a mapping from scores to probabilities [2].
[1] One possible corpus creation strategy might be math problems that you really need to run a program to solve. You can run the program to generate the correct answer key, but disallow tool calling for the AI.
[2] I'm pretty sure there's some stats wizardry that will let you put error bars on each bucket's probability based on the number of problems that end up in each bucket.
Perfect attendance is not a good goal to aspire to. Kids force themselves (or get forced by parents) to go to school while sick, which is probably bad for their health and also risks everybody else's health.
If a government is willing to go after the property of its own citizens without due process, foreign investors have to think: "What's to stop the same from happening to me?" Even if that foreign investor's a central bank.
[1] https://www.bitsaboutmoney.com/archive/debanking-and-debunki...
[2] Maybe the truckers' protest went too far; they were blocking roads. The point isn't whether they deserved to be punished; the point is that their accounts were frozen without going through the laws and court system.
[3] This was in 2022, so it has nothing to do with the current US administration.
reply