Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

“Rust is safe” is not some kind of absolute guarantee of code safety

lkml.org

Post reply on HN
Print view View original

501–510 of 542 posts

Re: “Rust is safe” is not some kind of absolute guarantee of code safety

#501

Post by atoav »

analognoise wrote: post #66
atoav wrote: post #16

Earlier quoted context omitted.

I mean if it is a cosmetic thing sure. If it has substantial meaning I would rather have that 5 ton robotic welding arm not move than have it move through my skill. It is sometimes acceptable to get wrong output. But is nearly always better to know it is wrong.

This sounds like the difference between "fault tolerant" and "fail safe". Fault tolerant - you get a fault, you keep moving. Fail safe - you fail, and thus all operations are stopped.

I mean the Rust appeal is actually that it foeces you to handle Errors. Whether you then fail or not is your decision. What Rust usually does not do is just fail.

This is good for when the things you are using could error, e.g. when you use an arbitrary unicode string as a filename you might get an error because depending on the OS there might be characters that you cannot use as filenames that are valid unicode (or the other way around, possible filenames that are not valid unicode).

In most programming languages this is something you need to know to catch it. In Rust this is an Error that you can or cannot handle. But you can't forget to deal with it.

Re: “Rust is safe” is not some kind of absolute guarantee of code safety

#502

Post by ok_dad »

gmueckl wrote: post #488
ok_dad wrote: post #471

Earlier quoted context omitted.

No, do you have a concrete example of this strawman, though? Edit: I should also add (probably earlier too) that all my examples are specific to the USA FDA process. I'm sure some other place might not have the same rules.

I can't see how you can make out a strawman in what I said. There are medical devices where the UI is running on a processor separate from the controller in charge of the core device functions. The two are talking to each other and there is no secondary way of interacting with the controller. This lessens the requirements that are put on the part running the UI, but does not eliminate them. I'm mostly familiar with E…

The UI is one of the most important parts of a machine, look at the Therac-25! The FDA regulations require a lot of effort goes into the human factors, too, and the UI definitely had to be as reliable as the rest of the device and be as well engineered as the rest.

https://www.fda.gov/medical-devices/human-factors-and-medica...

Honestly, the FDA regulations go too far vs the EU regs. The company I worked for was based in the EU and the products there were so advanced compared to our versions. Ours were all based on an original design from Europe that was approved and then basically didn’t charge for 30 years. The European device was fucking cool and had so many features, it was also capable of being carried around rather than rolled. The manufacturing was almost all automated, too, but in the USA it was not at all automated, it was humans assembling parts then recording it in a computer terminal.

Re: “Rust is safe” is not some kind of absolute guarantee of code safety

#503

Post by veber-alex »

jmillikin wrote: post #124
Tomte wrote: post #64

I actually wondered with all the recent "Rust in the kernel" about culture clashes. I mean, most kernel developers aren't Rust programmers (and vice versa). Now we got a first glimpse at what happens. Still, I find it strange that it never seemed to come up in preparation to the first Rust merges. Were there any conflict resolution strategies in place (that I don't know about) or just "we flame it out on LKML"?

I think this is more "[modern] userspace vs kernel" than "Rust vs kernel". If you dig slightly below the surface in any major userspace codebase, it has abort paths everywhere . Every memory allocation might abort, every array index or dict lookup might throw an exception, which if uncaught will abort. Lock (or unlock) a mutex twice, abort. The Rust standard library inherited this philosophy in large and small ways.…

> "integer math is allowed to panic on overflow"

This is configurable, by default with optimizations on math overflow doesn't panic in rust, it wraps around.

Obviously the kernel won't enable panics here unless in debug mode.

Re: “Rust is safe” is not some kind of absolute guarantee of code safety

#504

Post by lelanthran »

V_Terranova_Jr wrote: post #427
lelanthran wrote: post #422

Earlier quoted context omitted.

You're correct, it should be the default. But why are you complaining that a group of people who don't want to work in your default environment went off and created their own? I don't understand what you have to complain about: they have their way of working and you want to change that because it offends you? Sounds like you're the problem, not them.

Sounds like he's calling them out on an internet forum that they are also free to ignore. Doesn't sound like he's the problem.

> Sounds like he's calling them out on an internet forum that they are also free to ignore. Doesn't sound like he's the problem.

Well, I don't go around pointing out how random groups, formed by like-minded people voluntarily, are doing collaboration "wrong".

If I did, on some random internet forum, complain that the local Street Rod Enthusiasts Club[1] doesn't do proper agendas for their meetings, or that a book-reading club[1] that I know off isn't properly structured, or that the volunteer SPCA group is using the wrong IM/Chat software to communicate .. well, then I'm the problem.

[1] That I have no intention of joining

Re: “Rust is safe” is not some kind of absolute guarantee of code safety

#505

Post by kaba0 »

mike_hock wrote: post #202
EdSchouten wrote: post #138

Earlier quoted context omitted.

The policy of ‘oopsing’ and limping on is, in my opinion, literally one of Linux’s worst features. It has bitten me in various cases: - Remember when Linux had that caused the kernel to partially crash and eat 100% CPU due to some bug in the leap second application code? That caused a >1MW spike in power usage at Hetzner at the time. That must have been >1GW globally. Many people didn’t notice it immediately, so it m…

So instead of a power spike, we'd have had a major internet outage across the world, across the entire industry and beyond, probably, if everyone had panicked on oops. The blame really lies with people not monitoring their systems. As you said, you have the option to reboot on panic, but Linus is absolutely not wrong that this size does not fit all. What about a medical procedure that WILL kill the patient if interru…

That’s why monitoring, fail-safe power offs and redundant systems are important. E.g. even at the complete failure of a CAT scanner’s higher level control (which let’s say would run on an embedded linux kernel), the system would safely stop the radiation and power off, without any instructions from an OS. Here, an inconsistent state from the OS is actually more dangerous than stopping in the middle (e.g. the OS stucks and the same, high energy radiation is continuously being released)

Re: “Rust is safe” is not some kind of absolute guarantee of code safety

#506

Post by Kim_Bruning »

ok_dad wrote: post #242
mike_hock wrote: post #202

Earlier quoted context omitted.

So instead of a power spike, we'd have had a major internet outage across the world, across the entire industry and beyond, probably, if everyone had panicked on oops. The blame really lies with people not monitoring their systems. As you said, you have the option to reboot on panic, but Linus is absolutely not wrong that this size does not fit all. What about a medical procedure that WILL kill the patient if interru…

> What about a medical procedure that WILL kill the patient if interrupted? What about life support in space? Hitting an assert in those kinds of systems is a very bad place to be, but an automatic halt is worse than at least giving the people involved a CHANCE to try and get to a state where it's safe to take the system offline and restart it. Kinda a strawman there. That's got to account for, what, 0.0001% of all u…

Industrial control systems (sadly, imho) don't use Linux as often as they could/should, but such systems do have the ability to injure their operators or cause large amounts of damage of course. [1]

The first priority is safety, absolutely and without question. And then the immediate second priority is the fact that time is money. For every minute that the system is not operating, x amount of product is not being produced.

Generally, having the software fully halt on error is both dangerous and time-consuming.

Instead you want to switch to an ERROR and/or EMERGENCY_STOP state, where things like lasers or plasma torches get turned off, motors are stopped, brakes are applied, doors get locked/unlocked (as appropriate/safe), etc. And then you want to report that to the user, and give them tools to diagnose and correct the source of the error and to restart the machine/line [safely!] as quickly as possible.

In short, error handling and recovery is its own entire thing, and tends to be something that gets tested for separately during commissioning.

[1] PLC's do have the ability to and execute code in a real time manner, but I haven't encountered a lot of PLC programmers who actually exploit these abilities effectively. Basically for more complex situations you're quickly going to be better off with more general purpose tools [2], at most handing off critical tasks to PLCs, micro-controllers, or motor controllers etc.

[2] except for that stupid propensity to give-up-and-halt at exactly that moment where it'll cause the most damage.

Re: “Rust is safe” is not some kind of absolute guarantee of code safety

#507

Post by kaba0 »

GauntletWizard wrote: post #473
gmueckl wrote: post #436

Earlier quoted context omitted.

Yes, but why would you go to these lengths? The purpose of the whole mechanism is to prevent accidental misdiagnosis based on an incorrectly interpreted X-ray image. This isn't DRM, just a safeguard against incorrect use of equipment.

People are cheap and corrupt. The speed bump this presents is real, but minor, in the face of a couple medical shops looking to save $100/pop on a dozen monitors. I hope it's rare, but I think a persistent nag window ("Your display isn't calibrated and may not be accurate") is probably a better answer than refusing to work altogether, because it will be clear about the source of the problem and less likely to get nai…

Medical devices are insanely expensive (a CT scanner may reach a million dollars), you won’t risk $100 on such a small thing as a screen.

Re: “Rust is safe” is not some kind of absolute guarantee of code safety

#508

Post by kaba0 »

wtallis wrote: post #336
EdSchouten wrote: post #304

Earlier quoted context omitted.

One does not rule out the other. You could simply write crash info to some NVRAM or something, and then do a reboot. Then you can recover it during the next boot. But there is no need to let userspace processes continue to run, which is exactly what Linux does.

> You could simply write crash info to some NVRAM or something, and then do a reboot. Then you can recover it during the next boot. That works for some systems: those for which "some NVRAM or something" evaluates to a real device usable for that purpose. Not all Linux systems provide such a device. > But there is no need to let userspace processes continue to run, which is exactly what Linux does. Userspace processes…

Isn’t that exactly the reason behind microkernel’s supposed superiority?

Re: “Rust is safe” is not some kind of absolute guarantee of code safety

#509

Post by notacoward »

yencabulator wrote: post #465
notacoward wrote: post #421

Earlier quoted context omitted.

Perhaps. On the other hand, letting a medical device continue moving an actuator or dispensing a medication when it's known to be in a bad "never happen" state could also be fatal. Ditto for the "life support in space" example. Ditto for anything reliant on position, where the system suddenly realizes it has no idea whether its position is correct. Imagine that e.g. on a warship. Limiting responses to external inputs…

Picking medical devices and warships is also quite the cherry picking. Most Linuxes aren't like that. Critical embedded systems tend to have a hard realtime component, and if Linux is on the system it sits under e.g. seL4, or on a different CPU. At the end of the day, what Linux does is what Linus wants out of it. He's stated, often, that halting the CPU at the exact moment something goes wrong is not the goal. If yo…

> Picking medical devices ... is also quite the cherry picking

It wasn't my example. It was mike_hock's, and I was responding in the context they had set.

> Most Linuxes aren't like that.

Your ally picked the medical-device and space-life-support examples. If you think they're invalid because such systems don't use Linux, why did you forego bringing it up with them and then change course when replying to me? As I said: not helpful.

The point is not specific to Linux, and more Linux systems than you seem to be aware of do adopt the "crash before doing more damage" approach because they have some redundancy. If you're truly interested, I had another whole thread in this discussion explaining one class of such cases in what I feel was a reasonably informative and respectful way while another bad-faith interlocutor threw out little more than one-liners.

Re: “Rust is safe” is not some kind of absolute guarantee of code safety

#510

Post by notacoward »

yencabulator wrote: post #437
ChrisSD wrote: post #71

Earlier quoted context omitted.

What is better: continuing to "limp along" in some unknown corrupted state (aka undefined behaviour) or in a well defined (albeit invalid) state?

What is better for a desktop user: 1) needing to reload a wifi driver to reinitialize hardware (with a tiny probability of memory corruption) OR choosing to reboot as soon as convenient (with a tiny probability of corrupting the latest saved files) 2) to lose unsaved files for sure and not even know what caused the crash

Why focus exclusively on the desktop, or over-generalize from it to other uses? What is appropriate for them is not necessarily so for the many millions of machines in server rooms and data centers. Also, you present a false dichotomy. "Lose unsaved files for sure" is not the case for many systems, and "not even know" is not necessarily the case. Logging during shutdown is a real thing, as is saving a crash dump for retrieval after reboot. Both have been standard at my last several projects and companies.

As I've said over and over, both approaches - "limp along" and "reboot before causing harm" - need to remain options, for different scenarios. Anyone who treats the one use case they're familiar with as the only one which should drive policy for everyone is doing the community a disservice.

Post reply on HN