On Thu, Dec 18, 2008 at 2:02 PM, Erik Larsson <[email protected]> wrote: > Well, I could understand that for software builds that are used for > testing purposes, but this is production software that is installed in > thousands of Macs worldwide.
hopefully with the user's concent.... > I think users in general would feel more comfortable knowing that the > kernel extension they install will fail gracefully if some unexpected > condition occurs, however unlikely this situation may be. > Is the entire system stability threatened because of these unexpected > flags? probably. if you have an application writing stuff, and it thinks it successfully wrote it, and then its next step is to delete something else, and the writing won't behave correctly because it doesn't understand what it's been asked to do say you're doing: <move, HOMEDIR, ARCHIVE> And maybe the flag that you were passed meant _you_must_do_this_sync_, but you didn't understand that flag So the extension prepares a move (async), lets the callee think it succeeded (because it didn't understand this special api), and the callee then deletes HOMEDIR. Well, you lost everything :). Panics have uses. FWIW, I'm generally opposed to crashes and panics, but they really are necessary at times, and for things where you're essentially accepting a flag that could change how your module is supposed to behave, you really can't just ignore it. Now, if the api call is early enough, you could refuse to load, or force yourself to unload. but if it's in the middle of things, you probably can't. It'd be bad if the reverse happened, <move, ARCHIVE, HOMEDIR/data> and then <unknownmethod>. If unknownmethod decided to unmount the volume or change its behavior and that affected the currently running move ... well it's bad. > In that case I can understand the panic, but intuitively it seems > like something that it would be possible to recover from. fwiw, i'm not really into driver development. i try to stay at the browser layer, but i get used to debugging drivers which crash because of bad input. It's better to recognize bad input and fail fatally than not recognize it and be exploitable (which is actually why i'm on this list). --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "MacFUSE" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/macfuse?hl=en -~----------~----~----~----~------~----~------~--~---
