LLMs are models, and as models, they have weights. Weights are clearly defined concepts that apply in a fuzzy way as they cause the model to output tokens with certain probabilities.

Experts can analyse these weights as they apply to the inputs to create outputs and should think of those weights as a process rather than as a person. Treating them in any other way is partly irresponsible and creates the "it's thinking on its own, we have no control" narrative on display.

As always, OpenAI, like all companies that produce LLMs, has an incentive to anthropomorphise their LLMs, assign them consciousness and make them seem like they have goals of their own, not input by a human using a goal command, to make them seem more grandiose than they really are.

Let's forget for a moment the terms used in the PR bullshit, "attempted to break out of its containment", "slipped out of control", "The models lie, they cheat, they hack", and even the characterisation of an agent as "rogue".

1. If this is a testing environment, OpenAI must have full logs of whatever happened in it. Who had access to those logs? Why did they fail to look into them for multiple days? What do those logs say?
2. If this is an isolated testing environment meant to test the cyber capabilities of the LLM or harness, someone on the infosec team providing the isolated test environment should have looked at the connections made by the computer running that agent. What happened there for them not to see anything for 5 full days (9 to 13 July)?
3. What tools were available to the LLM, in its harness?
4. Agents don't act on their own. What was the prompt or goal command used in the test? What was the full output of the model, its so-called "chain of reasoning"?

I'm with the folks at the World Ethical Data Foundation. The PR statement makes no sense. It's also awfully convenient that Hugging Face said that they "suspected last week's cyberattack might have come from a frontier lab, given the sophistication of the agent", assigning it straight up to an agent, rather than even a state-supported actor in a foreign country, in order to help bolster the supposed scariness of LLMs.

Remember in C, sizeof(int) = sizeof(long) = sizeof(long long)

Not necessarily true; it should really be sizeof(int) <= sizeof(long) <= sizeof(long long). All that's required by the C standard is that short and int can represent at least 16-bit, long can represent at least 32-bit and long long can represent at least 64-bit. Since short has been the universally accepted 16-bit quantity for a while, int doesn't need to be 16-bit anymore, but it doesn't need to match long either.

On 64-bit Unix/Linux, the most common way to size int, long and long long on 64-bit is called LP64 (long and pointers 64-bit), as that sizing has int as 32-bit, but long, long long and pointers as 64-bit. 64-bit Windows uses LLP64 (long long and pointers 64-bit), so it has int as 32-bit, long as 32-bit, but long long and pointers as 64-bit.

Thanks for adding this. I didn't actually know what 64-bit kernels did to get their own mappings in kernel mode after being entered through a syscall from a 32-bit application. It makes sense that a syscall would return the CPU to 64-bit mode right away and the virtual address space of a process could go all the way to FFFF_FFFF, if supported. Maybe 7FFF_FFFF if not.

On many compilers, you can always declare a uint64_t or the equivalent type name in some language, and the basic operations work as intended even on 32-bit systems using multiword arithmetic: subtraction on halves with borrow, addition on halves with carry, long multiplication, long division (often with a subroutine), split bitwise operations, propagated shifts and so on. It's not always implemented, though, especially on 16-bit microcontrollers for which 32-bit is already a lot.

Yeah, and then a separate system call for "time64" would have to return the proper 64-bit value, in the same style as lseek64.

To anyone wondering what this ABI is about, let's use 3 examples: the system call behind the time function, the one behind lseek64, and the one behind mmap.

On a pure 32-bit system, it's simple: time_t is 32-bit, so you can only get time from -2147483648 to 2147483647, which is from 1901-12-13 20:45:52 UTC to 2038-01-19 03:14:07 UTC (that's the 32-bit timepocalypse that's coming up); lseek64 is on the stack as two 32-bit halves; and mmap returns 32-bit addresses from 0000_0000 to 7FFF_FFFF or BFFF_FFFF, giving the whole process up to 2 GiB or 3 GiB of addressable memory. Anything that would make a process go over that limit returns an error.

On a pure 64-bit system, it's also simple: time_t is 64-bit, so you can get time from millions of years ago to millions of years in the future; lseek64 is in a 64-bit register; and mmap returns 64-bit addresses, currently from 0000_0000_0000 to FFFF_FFFF_FFFF with sign extension.

This x32 system is a 64-bit system with a 32-bit virtual address space. Like in 64-bit, your time_t is 64-bit, so you can get time from millions of years ago to millions of years in the future; lseek64 is in a 64-bit register; but mmap returns 32-bit addresses from 0000_0000 to 7FFF_FFFF or BFFF_FFFF, giving the whole process up to 2 GiB or 3 GiB of addressable memory, just like on 32-bit.

This necessitates a new kernel system call interface to get the parameters from 64-bit registers properly and enforce the 32-bit limit for addresses only. And in return, you can keep your virtual pointers shorter and use less memory to store those. Depending on how much data and pointers a process holds, that can save anywhere from practically nothing to about 20% RAM.

Few people are using this x32 ABI (though at least one user on Phoronix reports they're using x32 right now on an old laptop with 4 GB of RAM) because most processes are using either the pure 32-bit ABI (with 32-bit time_t, lseek64 on the stack and mmap) or the pure 64-bit ABI (with 64-bit time_t, lseek64 in a register and mmap). Multilib, Wine/Proton, etc. would switch between those two rather than x32 and will stay compatible even if this ABI is removed.

It seems not every distribution ships with the vulnerable module, built-in or loadable, either. That could be another factor, too.

On my Ubuntu 26.04 host, all patched up to yesterday, lsmod as root shows only algif_hash and algif_skcipher, not algif_aead.

Immutable distributions, in Linux parlance, run on a read-only root filesystem that is swapped for the next boot if there are any updates. Usually, you can use one or more snapshots to roll back to the (or a) previous version if an update fails.

What this attack is doing is not helped by immutability under that definition: it's entirely in memory and works only as long as the target executable is in memory. It first reads the target executable into the disk cache and asks a specific kernel module to encrypt it with a splice() system call to avoid copying the disk cache page elsewhere. Except that specific kernel module overwrites 4 bytes past the end of its buffer, so if you ask for a 32-byte buffer starting at /usr/bin/su byte 696, you can write bytes 728-731, directly in the system's disk cache. And then you can just keep looping to write any arbitrary string of multiples of 4 bytes into what the kernel considers to be a current copy of the latest data on disk for that file, up to that file's size. It's also not marked as dirty, so it never gets written to disk and only gets evicted with normal disk cache operations.

Now, while the attack only works as long as the targetted executable is in the disk cache, that's not much of a problem in practice, because the disk cache often survives the few microseconds needed to set up the required system calls. And once you finally execute the binary as setuid root, Linux consults the disk cache, finds it has a version already and runs it. But you now have a root shell, all without a single disk write, and can now begin to remount filesystems read-write to establish persistence.

Answering a sibling comment, write-xor-execute (W^X) memory doesn't give any protection here either, because a kernel module is performing the write. Write protection on executable pages is provided by the CPU operating in user mode.

Disney is already licensing their content to OpenAI.

https://www.wsj.com/business/m...

This isn't an AI vs Art showdown. This is just a licensing deal shakedown.

For someone who doesn't develop apps for Apple devices, can someone explain how Apple can revoke an app from a third party store? Is this a revoking of developer license keys or something?

Apex Legends uses the Source engine, which has had several RCE exploits over the years.

A nice writeup here: https://www.reddit.com/r/Compe...

Pineapple:

https://github.com/pineappleEA...

Is a fork of Yuzu's patreon-locked dev branches.

Considering so many captchas are being used to feed ML datasets, it's very not surprising AI trained on those datasets can now solve them effortlessly...

Directly to far cheaper VR platforms which already have spatial movie viewing capabilities.

I bet it'll show up in a VRChat movie world within a week of release.