User: Password:
|
|
Subscribe / Log in / New account

No thanks.

No thanks.

Posted Nov 11, 2012 16:19 UTC (Sun) by paulj (subscriber, #341)
In reply to: No thanks. by raven667
Parent article: Haley: We're doing an ARM64 OpenJDK port!

If the internal state is compromised yes. However, you want to reject the bad actor's input before that happens. Parsing things with state machines and related automata, and cleanly rejecting invalid input (and dispensing with associated state) is not rocket science. (Note that method calls related to some piece of state can be viewed as inputs/transitions on an automaton).

Asserting and crashing should be a last resort in daemons that must provide shared-state services to multiple actors. While it is preferable to assert than to allow a security critical error, asserting itself may be a security critical error - handling errors cleanly is again preferable to the assert. A better approach is to have multiple layers of defence, with asserts against critical inconsistency errors at lower layers (e.g. forcing all IO through checked, bounded buffer abstractions), and well-defined automata at higher layers to provide clean error semantics (potentially multiple levels of such). You can't just restart, because of the shared-state. If you externalise the shared-state so that the code can be restarted, you still need to ensure that shared-state can never be manipulated into an inconsistent state.

All the world is a state machine, even the functional programming world. ;)


(Log in to post comments)


Copyright © 2018, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds