On Thu, Oct 03, 2013 at 11:15:11PM +0200, nazriel wrote:
> On Thursday, 3 October 2013 at 20:54:00 UTC, Walter Bright wrote:
> >On 10/3/2013 1:02 AM, Max Samukha wrote:
> >>That famous prejudice of yours :).
> >
> >Not just me, and I didn't invent it. It's a "prejudice" used by experienced engineers who build things that, if they fail, kill people. That prejudice is relearned, over and over, by bitter experience.
> >
> 
> Music player (as example) do not kill people if they fail. Aborting whole music player just because Visualisation plugin had access violation is pointless.

Run the plugin in a sandbox.


T

-- 
INTEL = Only half of "intelligence".

On 10/3/2013 2:15 PM, nazriel wrote:
> Music player (as example) do not kill people if they fail.
> Aborting whole music player just because Visualisation plugin had access
> violation is pointless.

How does the music player know the fault is in the plugin and it could be safely continued?

It doesn't. It cannot. With a shared address space, it could be anywhere.


> You can't put every use case into the same bag...

I doubt the users would be pleased if continuing running the program resulted in further corruption of the system, including the user's data. Yes, and I've used music players that did that. It sux having to rebuild the music database from backups every time. It doesn't make me think kindly of the player's developers.

A properly designed system with user-supplied plugins that needed to recover from plugin failure would put those plugins in a separate process space, so when they crash they cannot affect the rest of the system. Any other scheme is just a bad design, although it may be convenient from a developer cost standpoint to write it that way.

And lastly, such badly designed plugin systems are rich vectors for people to insert malware into your system. See ActiveX for an example.

On 04.10.2013 00:38, Walter Bright wrote:
> On 10/3/2013 2:15 PM, nazriel wrote:
>> Music player (as example) do not kill people if they fail.
>> Aborting whole music player just because Visualisation plugin had access
>> violation is pointless.
>
> How does the music player know the fault is in the plugin and it could
> be safely continued?
>
> It doesn't. It cannot. With a shared address space, it could be anywhere.
>
>
>> You can't put every use case into the same bag...
>
> I doubt the users would be pleased if continuing running the program
> resulted in further corruption of the system, including the user's data.
> Yes, and I've used music players that did that. It sux having to rebuild
> the music database from backups every time. It doesn't make me think
> kindly of the player's developers.
>
> A properly designed system with user-supplied plugins that needed to
> recover from plugin failure would put those plugins in a separate
> process space, so when they crash they cannot affect the rest of the
> system. Any other scheme is just a bad design, although it may be
> convenient from a developer cost standpoint to write it that way.
>
> And lastly, such badly designed plugin systems are rich vectors for
> people to insert malware into your system. See ActiveX for an example.


This is actually one of the reasons Go guys are so opinated against dynamic linking.

I used to complain about it on gonuts forums, but eventually came to realize, that I was a bit spoiled by dynamic loading for plugins and the old UNIX model of processes for plugins is what makes more sense from the security point of view.

And it is the trend we are seeing nowadays with the integration of micro-kernel techniques in mainstream OSs.

Gatekeeper in Mac OS X/iOS, user space drivers in Windows, FF and Chrome plugin APIs, ...

Plugins as dynamic libraries open the door for great customizations, but
they open the door for possible instability of the host application and
security exploits.

--
Paulo

On Thursday, 3 October 2013 at 22:38:18 UTC, Walter Bright wrote:
> On 10/3/2013 2:15 PM, nazriel wrote:
>> Music player (as example) do not kill people if they fail.
>> Aborting whole music player just because Visualisation plugin had access
>> violation is pointless.
>
> How does the music player know the fault is in the plugin and it could be safely continued?
>

Because a music player can ALWAYS safely continue. Worst case scenario, if behave erratically and is killed by user.

A car firmware kill people if they behave erratically. The right choice is to kill it if anything look wrong.

A media player won't kill anyone.

> A properly designed system with user-supplied plugins that needed to recover from plugin failure would put those plugins in a separate process space, so when they crash they cannot affect the rest of the system. Any other scheme is just a bad design, although it may be convenient from a developer cost standpoint to write it that way.
>

Yes. Anything is a cost benefit tradeoff. The cost of developing a sandboxing solution is way higher than doing some recovery that will fail in 1% of the case in a way that won't kill anyone.

And unless phobos get a sandboxing solution builtin, the argument will stand.

On Thursday, 3 October 2013 at 23:18:32 UTC, deadalnix wrote:
> And unless phobos get a sandboxing solution builtin, the argument will stand.

pipeProcess is an ok starting point. (Though when I tried to use it recently, the fact that it didn't support async i/o on Windows meant I had to roll my own anyway...) but if you spawned the plugin as a process and then just sent/received messages through the pipes it isn't too hard to make an application out of it, especially with an rpc library too.

On Friday, October 04, 2013 01:18:31 deadalnix wrote:
> On Thursday, 3 October 2013 at 22:38:18 UTC, Walter Bright wrote:
> > On 10/3/2013 2:15 PM, nazriel wrote:
> >> Music player (as example) do not kill people if they fail.
> >> Aborting whole music player just because Visualisation plugin
> >> had access
> >> violation is pointless.
> > 
> > How does the music player know the fault is in the plugin and it could be safely continued?
> 
> Because a music player can ALWAYS safely continue. Worst case scenario, if behave erratically and is killed by user.
> 
> A car firmware kill people if they behave erratically. The right choice is to kill it if anything look wrong.
> 
> A media player won't kill anyone.

Just because it won't kill anyone doesn't mean that it's okay for it to continue after it's in a bad state. It could do other nasty things to the system (including corrupt the files that it's operating on). Once a program's in an invalid state, all bets are off. I fully concur with Walter that it's better to kill the program at that point and restart it whether lives are on the line or not. And if that means that the user sees crashes, oh well. They'll complain and the developer will have to fix them, which is exactly what they need to do, because they wouldn't be getting stuff like segfaults or Errors if their code wasn't broken.

- Jonathan M Davis

On 04.10.2013 01:49, Jonathan M Davis wrote:
> On Friday, October 04, 2013 01:18:31 deadalnix wrote:
>> On Thursday, 3 October 2013 at 22:38:18 UTC, Walter Bright wrote:
>>> On 10/3/2013 2:15 PM, nazriel wrote:
>>>> Music player (as example) do not kill people if they fail.
>>>> Aborting whole music player just because Visualisation plugin
>>>> had access
>>>> violation is pointless.
>>>
>>> How does the music player know the fault is in the plugin and
>>> it could be safely continued?
>>
>> Because a music player can ALWAYS safely continue. Worst case
>> scenario, if behave erratically and is killed by user.
>>
>> A car firmware kill people if they behave erratically. The right
>> choice is to kill it if anything look wrong.
>>
>> A media player won't kill anyone.
>
> Just because it won't kill anyone doesn't mean that it's okay for it to
> continue after it's in a bad state. It could do other nasty things to the
> system (including corrupt the files that it's operating on). Once a program's
> in an invalid state, all bets are off. I fully concur with Walter that it's
> better to kill the program at that point and restart it whether lives are on
> the line or not. And if that means that the user sees crashes, oh well.
> They'll complain and the developer will have to fix them, which is exactly what
> they need to do, because they wouldn't be getting stuff like segfaults or
> Errors if their code wasn't broken.
>
> - Jonathan M Davis
>


Fully agree. We only got in the sore point of today's industry quality because people got used to have broken applications.

Noone is happy driving a car that kind of works, shoes with shoelaces that will only work in nights of full moon, ....

Quality should be always a concern, not only when people lives are at stake.

--
Paulo

On 10/3/2013 4:49 PM, Jonathan M Davis wrote:
> Just because it won't kill anyone doesn't mean that it's okay for it to
> continue after it's in a bad state. It could do other nasty things to the
> system (including corrupt the files that it's operating on). Once a program's
> in an invalid state, all bets are off. I fully concur with Walter that it's
> better to kill the program at that point and restart it whether lives are on
> the line or not. And if that means that the user sees crashes, oh well.
> They'll complain and the developer will have to fix them, which is exactly what
> they need to do, because they wouldn't be getting stuff like segfaults or
> Errors if their code wasn't broken.

Exactly.

Note that memory corruption can also result in corruption of user data, as I mentioned, and it can ALSO result in corruption of your system. The music player can read and write files, right? Kaboom.

I was just talking to Andrei earlier about the bad old MSDOS programming days. There, if you had an errant pointer, it didn't seg fault. It would scramble the operating system tables, and having

    YOUR HARD DISK SCRAMBLED

was a not uncommon experience.

Continuing program execution after it failed due to programming bugs is just a bad, bad, bad idea, and it needs to die.

On Thu, Oct 03, 2013 at 07:49:16PM -0400, Jonathan M Davis wrote:
> On Friday, October 04, 2013 01:18:31 deadalnix wrote:
> > On Thursday, 3 October 2013 at 22:38:18 UTC, Walter Bright wrote:
> > > On 10/3/2013 2:15 PM, nazriel wrote:
> > >> Music player (as example) do not kill people if they fail. Aborting whole music player just because Visualisation plugin had access violation is pointless.
> > > 
> > > How does the music player know the fault is in the plugin and it could be safely continued?
> > 
> > Because a music player can ALWAYS safely continue. Worst case scenario, if behave erratically and is killed by user.
> > 
> > A car firmware kill people if they behave erratically. The right choice is to kill it if anything look wrong.
> > 
> > A media player won't kill anyone.
> 
> Just because it won't kill anyone doesn't mean that it's okay for it to continue after it's in a bad state. It could do other nasty things to the system (including corrupt the files that it's operating on). Once a program's in an invalid state, all bets are off. I fully concur with Walter that it's better to kill the program at that point and restart it whether lives are on the line or not. And if that means that the user sees crashes, oh well.  They'll complain and the developer will have to fix them, which is exactly what they need to do, because they wouldn't be getting stuff like segfaults or Errors if their code wasn't broken.
[...]

Reminds me of a GUI app I tried years ago, that suffered from some kind of memory corruption bug. Every now and then it would segfault due to hitting the corruption... one time, it *didn't* segfault, but continued merrily on and corrupted all of my data -- worth many hours of work -- all without showing any signs of problems, and then out of habit I saved the file I was working on, and it barged ahead and wrote garbage all over my last good copy of the data. :-(

Now, I don't think it had segfault recovery, but even without, it was already bad enough. I don't think I ever want to find out what that program would've done if it came *with* segfault recovery... (think about all those times it crashed *before* the bad data got saved into the file.)


T

-- 
Never ascribe to malice that which is adequately explained by incompetence. -- Napoleon Bonaparte

On Thu, Oct 03, 2013 at 05:04:02PM -0700, Walter Bright wrote:
> On 10/3/2013 4:49 PM, Jonathan M Davis wrote:
> >Just because it won't kill anyone doesn't mean that it's okay for it to continue after it's in a bad state. It could do other nasty things to the system (including corrupt the files that it's operating on). Once a program's in an invalid state, all bets are off. I fully concur with Walter that it's better to kill the program at that point and restart it whether lives are on the line or not. And if that means that the user sees crashes, oh well.  They'll complain and the developer will have to fix them, which is exactly what they need to do, because they wouldn't be getting stuff like segfaults or Errors if their code wasn't broken.
> 
> Exactly.
> 
> Note that memory corruption can also result in corruption of user data, as I mentioned, and it can ALSO result in corruption of your system. The music player can read and write files, right? Kaboom.
> 
> I was just talking to Andrei earlier about the bad old MSDOS programming days. There, if you had an errant pointer, it didn't seg fault. It would scramble the operating system tables, and having
> 
>     YOUR HARD DISK SCRAMBLED
> 
> was a not uncommon experience.

Ah yes, those were the days when you *always* kept a full backup of a fully-working snapshot of your OS and dev environment on a separate floppy, so that when your program inevitably crashed / destroyed the OS, you could power off and reboot from the good copy (and promptly make another copy thereafter, in order to not also destroy the last good disk!). Hitting reset / power cycling several times an hour was pretty common, since the most trivial of bugs easily caused the system to hang, or get stuck in graphics mode with no way to (easily) switch it back, or lock up the keyboard somehow, or do any number of other erratic things.

Write to a wrong memory address (e.g., dereference a wrong pointer), and boom, you just broke DOS in a subtle way that only shows up the next time you write to a file. Write to another wrong memory address, and boom, one of DOS's core routines got overwritten, now disk I/O doesn't work, or DOS just hangs and won't respond to anything. Jump to an invalid func ptr with the wrong value, and boom, you just entered the DOS FORMAT routine. Bye bye sweet data, it was nice knowing you.


> Continuing program execution after it failed due to programming bugs is just a bad, bad, bad idea, and it needs to die.

Heh, my Perl script actually picked a vaguely relevant signature line on its own this time, without manual intervention. :-P


T

-- 
If you want to solve a problem, you need to address its root cause, not just its symptoms. Otherwise it's like treating cancer with Tylenol...