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

Threat models for embedded devices

Threat models for embedded devices

Posted Apr 19, 2010 11:49 UTC (Mon) by Darkmere (subscriber, #53695)
In reply to: Threat models for embedded devices by kpvangend
Parent article: Threat models for embedded devices

I'm in a bit of a bind here myself. I'm just starting development on an embedded project that will go out to tinkerers. However, due to the support nightmare that is customized service&hardware model in question, I'd love to be able to sign off at least the supported binaries.

That means, they would be allowed (and okay) to run other software, as long as the "core functionality" can be verified as unmanipulated, simply so we say "you changed it, keep all the pieces" in support.

So yes, we are partially in that same boat, but for a business reason I cannot argue with. Supporting modified binaries would cause a pain. So would it if they were to add too much software and the oom-killer would hit the core software (which can't normally go oom due to careful vetting)

So, what should I do in a situation like this? Soak a support cost, trust customers honesty, or try and prevent my headache?


(Log in to post comments)

Threat models for embedded devices

Posted Apr 19, 2010 21:34 UTC (Mon) by nix (subscriber, #2304) [Link]

You can prevent the oom-killer from ever killing your core software by echoing -17 to /proc/$pid/oom_adj (root required, so you'll need a setuid wrapper or something).

Threat models for embedded devices

Posted Jul 4, 2010 22:47 UTC (Sun) by oak (guest, #2786) [Link]

That's only valid until such processes themselves (or their children inheriting the property) exhaust the memory...


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