▲ 182 ▼ Linux Kernel Rust Code Sees Its First CVE Vulnerability (www.phoronix.com) submitted 10 months ago by hal_5700X@sh.itjust.works to c/technology@lemmy.world 46 comments fedilink hide all child comments
[–] john_t@piefed.ee 105 points 10 months ago (10 children) No one said rust was invulnerable. permalink fedilink source hideshow 10 child comments replies: [–] pryre@lemmy.world 80 points 10 months ago (5 children) I think the other takeaway here is that it was found in a section marked "unsafe". At the very least, that's a useful tool for the Devs to isolate potential problem areas. Comparing that to a pure C codebase where the problem could be anywhere. permalink fedilink source parent hideshow 5 child comments replies: [–] hummingbird@lemmy.world 1 point 10 months ago (2 children) The funny part is: the fix does not change the unsafe block at all. The issue is elsewhere in safe rust code. permalink fedilink source parent hideshow 2 child comments replies: [–] KexPilot@lemmy.world 4 points 10 months ago* No. The issue is that an assumption they make in the unsafe block does not actually always hold true. They changed the safe rust code to strenghten the (incorrect) assumption they made in the first place, because that is way easier than rearchitecting the unsafe part. I.e. if the unsafe part was somehow to be written safely, the mitigation they introduced now would not result in any difference in behaviour, it would be correct behaviour both before and after. Tldr: the problem lies in the unsafe part permalink fedilink source parent [–] pryre@lemmy.world 2 points 10 months ago I'll admit, I haven't looked at the code. I would stand by my comment of the unsafe block being a start point. Countering that however, what is the difference to just debugging effectively? Not sure. I suppose it's down to the people that identified it and fixed it at the end of the day to say if there was any benefit. permalink fedilink source parent [–] vrighter@discuss.tchncs.de -3 points 10 months ago (1 child) doesn't change anything if you can't avoid having to write the unsafe parts permalink fedilink source parent hideshow 1 child comment replies: [–] nsfw936421@lemmynsfw.com 9 points 10 months ago It certainly does. It's way simpler to keep up all invariants and to review the few percent lines of code in unsafe blocks than making sure that the 30 million lines of code are free of undefined behavior. Is some part of the code it battle tested of course it's complete unreasonable to rewrite it in any language, but if you have to do a major rewrite anyway or write a new component you should definitely use a memory safe language. And no it doesn't matter that there is an unsafe escape hatch because it's literally impossible to write low level kernel stuff or FFI to other languages without unsafe because Rust can't uphold/guarantee the invariants of the hardware itself or the behavior of other languages. permalink fedilink source parent [–] BassTurd@lemmy.world 11 points 10 months ago (3 children) Boone? There are plenty of fan boys out there that are selling rust like AI, or in other words snake oil. Rust obviously has built in securities that C doesn't have, but a shitty coder is a shitty coder and bad QC is bad QC. Now we're seeing the reality of the consequences. Rust and/or other memory safe(r) languages are like the future, but hopefully more people are now seeing the cracks. Just look at cloudflare for a prime example. permalink fedilink source parent hideshow 3 child comments replies: [–] pupbiru@aussie.zone 7 points 10 months ago (2 children) the cloudflare issues were configuration… they have nothing even remotely relayed to any of this permalink fedilink source parent hideshow 2 child comments replies: [–] PushButton@lemmy.world -1 points 10 months ago (1 child) thread fl2_worker_thread panicked: called Result::unwrap() on an Err value permalink fedilink source parent hideshow 1 child comment replies: [–] pupbiru@aussie.zone 8 points 10 months ago The software had a limit on the size of the feature file that was below its doubled size. That caused the software to fail. this is not a rust problem… nor was the original problem of code writing entries to a file multiple times, and nor is the thing that made it worse: propagation of the poisoned file permalink fedilink source parent
[–] pryre@lemmy.world 80 points 10 months ago (5 children) I think the other takeaway here is that it was found in a section marked "unsafe". At the very least, that's a useful tool for the Devs to isolate potential problem areas. Comparing that to a pure C codebase where the problem could be anywhere. permalink fedilink source parent hideshow 5 child comments replies: [–] hummingbird@lemmy.world 1 point 10 months ago (2 children) The funny part is: the fix does not change the unsafe block at all. The issue is elsewhere in safe rust code. permalink fedilink source parent hideshow 2 child comments replies: [–] KexPilot@lemmy.world 4 points 10 months ago* No. The issue is that an assumption they make in the unsafe block does not actually always hold true. They changed the safe rust code to strenghten the (incorrect) assumption they made in the first place, because that is way easier than rearchitecting the unsafe part. I.e. if the unsafe part was somehow to be written safely, the mitigation they introduced now would not result in any difference in behaviour, it would be correct behaviour both before and after. Tldr: the problem lies in the unsafe part permalink fedilink source parent [–] pryre@lemmy.world 2 points 10 months ago I'll admit, I haven't looked at the code. I would stand by my comment of the unsafe block being a start point. Countering that however, what is the difference to just debugging effectively? Not sure. I suppose it's down to the people that identified it and fixed it at the end of the day to say if there was any benefit. permalink fedilink source parent [–] vrighter@discuss.tchncs.de -3 points 10 months ago (1 child) doesn't change anything if you can't avoid having to write the unsafe parts permalink fedilink source parent hideshow 1 child comment replies: [–] nsfw936421@lemmynsfw.com 9 points 10 months ago It certainly does. It's way simpler to keep up all invariants and to review the few percent lines of code in unsafe blocks than making sure that the 30 million lines of code are free of undefined behavior. Is some part of the code it battle tested of course it's complete unreasonable to rewrite it in any language, but if you have to do a major rewrite anyway or write a new component you should definitely use a memory safe language. And no it doesn't matter that there is an unsafe escape hatch because it's literally impossible to write low level kernel stuff or FFI to other languages without unsafe because Rust can't uphold/guarantee the invariants of the hardware itself or the behavior of other languages. permalink fedilink source parent
[–] hummingbird@lemmy.world 1 point 10 months ago (2 children) The funny part is: the fix does not change the unsafe block at all. The issue is elsewhere in safe rust code. permalink fedilink source parent hideshow 2 child comments replies: [–] KexPilot@lemmy.world 4 points 10 months ago* No. The issue is that an assumption they make in the unsafe block does not actually always hold true. They changed the safe rust code to strenghten the (incorrect) assumption they made in the first place, because that is way easier than rearchitecting the unsafe part. I.e. if the unsafe part was somehow to be written safely, the mitigation they introduced now would not result in any difference in behaviour, it would be correct behaviour both before and after. Tldr: the problem lies in the unsafe part permalink fedilink source parent [–] pryre@lemmy.world 2 points 10 months ago I'll admit, I haven't looked at the code. I would stand by my comment of the unsafe block being a start point. Countering that however, what is the difference to just debugging effectively? Not sure. I suppose it's down to the people that identified it and fixed it at the end of the day to say if there was any benefit. permalink fedilink source parent
[–] KexPilot@lemmy.world 4 points 10 months ago* No. The issue is that an assumption they make in the unsafe block does not actually always hold true. They changed the safe rust code to strenghten the (incorrect) assumption they made in the first place, because that is way easier than rearchitecting the unsafe part. I.e. if the unsafe part was somehow to be written safely, the mitigation they introduced now would not result in any difference in behaviour, it would be correct behaviour both before and after. Tldr: the problem lies in the unsafe part permalink fedilink source parent
[–] pryre@lemmy.world 2 points 10 months ago I'll admit, I haven't looked at the code. I would stand by my comment of the unsafe block being a start point. Countering that however, what is the difference to just debugging effectively? Not sure. I suppose it's down to the people that identified it and fixed it at the end of the day to say if there was any benefit. permalink fedilink source parent
[–] vrighter@discuss.tchncs.de -3 points 10 months ago (1 child) doesn't change anything if you can't avoid having to write the unsafe parts permalink fedilink source parent hideshow 1 child comment replies: [–] nsfw936421@lemmynsfw.com 9 points 10 months ago It certainly does. It's way simpler to keep up all invariants and to review the few percent lines of code in unsafe blocks than making sure that the 30 million lines of code are free of undefined behavior. Is some part of the code it battle tested of course it's complete unreasonable to rewrite it in any language, but if you have to do a major rewrite anyway or write a new component you should definitely use a memory safe language. And no it doesn't matter that there is an unsafe escape hatch because it's literally impossible to write low level kernel stuff or FFI to other languages without unsafe because Rust can't uphold/guarantee the invariants of the hardware itself or the behavior of other languages. permalink fedilink source parent
[–] nsfw936421@lemmynsfw.com 9 points 10 months ago It certainly does. It's way simpler to keep up all invariants and to review the few percent lines of code in unsafe blocks than making sure that the 30 million lines of code are free of undefined behavior. Is some part of the code it battle tested of course it's complete unreasonable to rewrite it in any language, but if you have to do a major rewrite anyway or write a new component you should definitely use a memory safe language. And no it doesn't matter that there is an unsafe escape hatch because it's literally impossible to write low level kernel stuff or FFI to other languages without unsafe because Rust can't uphold/guarantee the invariants of the hardware itself or the behavior of other languages. permalink fedilink source parent
[–] BassTurd@lemmy.world 11 points 10 months ago (3 children) Boone? There are plenty of fan boys out there that are selling rust like AI, or in other words snake oil. Rust obviously has built in securities that C doesn't have, but a shitty coder is a shitty coder and bad QC is bad QC. Now we're seeing the reality of the consequences. Rust and/or other memory safe(r) languages are like the future, but hopefully more people are now seeing the cracks. Just look at cloudflare for a prime example. permalink fedilink source parent hideshow 3 child comments replies: [–] pupbiru@aussie.zone 7 points 10 months ago (2 children) the cloudflare issues were configuration… they have nothing even remotely relayed to any of this permalink fedilink source parent hideshow 2 child comments replies: [–] PushButton@lemmy.world -1 points 10 months ago (1 child) thread fl2_worker_thread panicked: called Result::unwrap() on an Err value permalink fedilink source parent hideshow 1 child comment replies: [–] pupbiru@aussie.zone 8 points 10 months ago The software had a limit on the size of the feature file that was below its doubled size. That caused the software to fail. this is not a rust problem… nor was the original problem of code writing entries to a file multiple times, and nor is the thing that made it worse: propagation of the poisoned file permalink fedilink source parent
[–] pupbiru@aussie.zone 7 points 10 months ago (2 children) the cloudflare issues were configuration… they have nothing even remotely relayed to any of this permalink fedilink source parent hideshow 2 child comments replies: [–] PushButton@lemmy.world -1 points 10 months ago (1 child) thread fl2_worker_thread panicked: called Result::unwrap() on an Err value permalink fedilink source parent hideshow 1 child comment replies: [–] pupbiru@aussie.zone 8 points 10 months ago The software had a limit on the size of the feature file that was below its doubled size. That caused the software to fail. this is not a rust problem… nor was the original problem of code writing entries to a file multiple times, and nor is the thing that made it worse: propagation of the poisoned file permalink fedilink source parent
[–] PushButton@lemmy.world -1 points 10 months ago (1 child) thread fl2_worker_thread panicked: called Result::unwrap() on an Err value permalink fedilink source parent hideshow 1 child comment replies: [–] pupbiru@aussie.zone 8 points 10 months ago The software had a limit on the size of the feature file that was below its doubled size. That caused the software to fail. this is not a rust problem… nor was the original problem of code writing entries to a file multiple times, and nor is the thing that made it worse: propagation of the poisoned file permalink fedilink source parent
[–] pupbiru@aussie.zone 8 points 10 months ago The software had a limit on the size of the feature file that was below its doubled size. That caused the software to fail. this is not a rust problem… nor was the original problem of code writing entries to a file multiple times, and nor is the thing that made it worse: propagation of the poisoned file permalink fedilink source parent