Even programs are just specifications by that standard. When you write a program in C, you are describing what an abstract C machine can do. When the C compiler turns that into a program it is free to do so in any way that is consistent with the abstract C machine.
If you look at what implementions modern compilers actually come up with, they often look quite different from what you would expect from the source code
Compilers are converters. There’s the abstract machine specified by the standard and there’s the real machine where the program will run (and there can be some layer in between). So compilers takes your program (which assumes the abstract machine) and builds the link between the abstract and the real.
If your program was a DSL for steering, the abstract machine will be the idea of steering wheel, while the machine could be a car without one. So a compiler would build the steering wheel, optionally adding power steering (optimization), and then tack the apparatus to steer for the given route.
I think there are two distinct attack types for LLMs. Jailbreaking is what most people think of, and consists of structureing a prompt so the LLM does what the prompt says, even if it had prior context saying not to.
The other type of attack would be what I would call "induced hallucinations", where the attacker crafts data not to get the LLM to do anything the data says, but to do what the attacker wants.
This is a common attack to demonstrate on neural network based image classifiers. Start with a properly classified image, and a desired incorrect classification. Then, introduce visually imperceptible noise until the classifier reports it as your target classification. There is no data/instruction confusion here: it is all data.
The core problem is that neural networks are fairly linear (which is what makes it possible to construct efficient hardware for them). They are, of course, not actually linear functions, but close enough to make linear algebra based attacks feasible.
It is probably better to think of this sort of attack in term of crypto analysis, which frequently exploits linearity in cryptosystems.
The depth of LLM networks make this sort of attack difficult; but I don't see any reason to think you can add enough layers to make it impossible. Particularly given that there is other research showing structure across layers, with groupings of layers having identifiable functionality. This means it is probably possible to reason about attacking individual layers like an onion.
This problem isn't really unique to AI either. Human written code has a tendency to be vulnerable to a similar attack, where maliciously crafted data can exploit the processor to do anything (e.g buffer overflow into arbitrary code execution).
It's not clear from the article, but "niche optimization" does not mean "optimization that is only useful in a very specific circumstance".
It is a specific optimization based on the idea of storing one type inside of another type by finding a "niche" of unused bit pattern(s) inside the second type.
It has far more useful application than a tower of Option 254 deep.
I doubt they were thinking about Option<bool> when making niches work like this.
Option<NonZeroU32> seems like a much more reasonable to justify this with. Also, enums can easily have invalid bit patterns that are unused without there being any specific bit that is always available. All you need is a single variant of the enum to have a free bit, and you have a niche to shove None into.
I'm surprised that trinary logic has not become a standard part of standard libraries yet. Almost every project I have worked on ends up with some form of a yes/no/maybe abstraction.
Yes/No/Maybe is a good fit for an enum because “Maybe” carries some specific information.
For more common situations where the yes/no bool is not available yet or should not be considered, constructs like Rust’s Option<bool> are a very good fit. Layering the bool inside of an Option creates intentional handling about the presence or lack of value first before you can work with it.
No. SELinux is based on the Linux Security Module framework, which places explicit hooks at key points within the kernel.
They also operate under pretty fundamentally different philosophies. Seccomp is based on a program dropping its own permissions. SELinux is based on a system integrator writing an ahead of time policy restricting what a program can do.
You can mostly do that with Seccomp on Linux (I have no experience with FreeBSD).
Child processes inherit the restrictions from the parent. You can therefore have the parent fork, setup it's rules, then exec. This is exactly how syscall filtering (and a bunch of other lockdowns) are implemented in SystemD
Refundable tax credits are a thing the government knows how to do. If a negative income tax law was written to allow refunds to people who owe net negative taxes, the IRS could do it.
This isn't a case where you need bug free software. This is a case where the frequency of fatal bugs is directly proportional to the support cost. Fix the common bugs, then write off the support for rare ones as a cost of doing business.
The effect of cheap robo support is not reducing the cost of support. It is reducing the cost of development by enabling a more buggy product while maintaining the previous support costs.
If you look at what implementions modern compilers actually come up with, they often look quite different from what you would expect from the source code
reply