31–40 of 107 posts
There's easily thousands of such bugs hidden in the kernel. Reminder the kernel has over ten million LoCs, or megabytes of object code. Perhaps we should start thinking about whether it is a good idea to run something this large in supervisor mode, with full privileges. I wouldn't say it is sensible in a world where seL4 exists.
Earlier quoted context omitted.
Aren't iptables just an emulation layer on top of netfilter?
Probably depends on the distro. Iptables is a wrapper around nftables in most distros, but probably not all.
If it says (nf_tables), you are using the compatibility layer from the iptables-nft package.
It works quite well. Apps like Docker that inserts rules using the legacy iptables syntax are oblivious to the fact that they are actually inserting nftables rules.
It also provides an easy migration path. Insert your old rules using your iptables script then list them in the new syntax using nft list ruleset.
The problem is that it works so well that it seems most users just stayed with the iptables syntax and did not bother migrating at all.
There's easily thousands of such bugs hidden in the kernel. Reminder the kernel has over ten million LoCs, or megabytes of object code. Perhaps we should start thinking about whether it is a good idea to run something this large in supervisor mode, with full privileges. I wouldn't say it is sensible in a world where seL4 exists.
Earlier quoted context omitted.
I wouldn't generally expect a use-after-free to result from improper pointer arithmetic; that's the recipe for a buffer overflow. But Rust happens to also be well-known for helping manage object lifetimes, which seems to be what went wrong here.
I'm not sure if your claim here is correct. The patch is to change call sites like priv->set->use++; To look like: nf_tables_activate_set(ctx, priv->set); Where this function is defined as: void nf_tables_activate_set(const struct nft_ctx *ctx, struct nft_set *set) { if (nft_set_is_anonymous(set)) nft_clear(ctx->net, set); set->use++; } So to me (someone who is not an expert in this code) it looks like the fix is che…
Earlier quoted context omitted.
I wouldn't generally expect a use-after-free to result from improper pointer arithmetic; that's the recipe for a buffer overflow. But Rust happens to also be well-known for helping manage object lifetimes, which seems to be what went wrong here.
I'm not sure if your claim here is correct. The patch is to change call sites like priv->set->use++; To look like: nf_tables_activate_set(ctx, priv->set); Where this function is defined as: void nf_tables_activate_set(const struct nft_ctx *ctx, struct nft_set *set) { if (nft_set_is_anonymous(set)) nft_clear(ctx->net, set); set->use++; } So to me (someone who is not an expert in this code) it looks like the fix is che…
More generally: doing a line-by-line translation from C to Rust is never going to be the best way to make use of the capabilities Rust has that C lacks.
There's easily thousands of such bugs hidden in the kernel. Reminder the kernel has over ten million LoCs, or megabytes of object code. Perhaps we should start thinking about whether it is a good idea to run something this large in supervisor mode, with full privileges. I wouldn't say it is sensible in a world where seL4 exists.
Microkernel does seem the only sensible path forward. Even if the kernel is slowly rustified, going to be playing security whack-a-mole for a long time.
There's easily thousands of such bugs hidden in the kernel. Reminder the kernel has over ten million LoCs, or megabytes of object code. Perhaps we should start thinking about whether it is a good idea to run something this large in supervisor mode, with full privileges. I wouldn't say it is sensible in a world where seL4 exists.
There's easily thousands of such bugs hidden in the kernel. Reminder the kernel has over ten million LoCs, or megabytes of object code. Perhaps we should start thinking about whether it is a good idea to run something this large in supervisor mode, with full privileges. I wouldn't say it is sensible in a world where seL4 exists.
There's easily thousands of such bugs hidden in the kernel. Reminder the kernel has over ten million LoCs, or megabytes of object code. Perhaps we should start thinking about whether it is a good idea to run something this large in supervisor mode, with full privileges. I wouldn't say it is sensible in a world where seL4 exists.
Alternatively, perhaps we should start thinking about whether it is a good idea to have multiple users of different privilege sharing the same hardware.