Learn how to design and defend an embedded Linux device
embeddedbits.org
Learn how to design and defend an embedded Linux device
1–10 of 36 posts
Re: Learn how to design and defend an embedded Linux device
#2This is really good! Thank you for writing something that's so easy to understand.
Re: Learn how to design and defend an embedded Linux device
#3This is a bad article. No practical technical discussion on topic. Many flowcharts, and bizspeak.
Re: Learn how to design and defend an embedded Linux device
#4This article recommends that manufacturers put the Secure Boot public key in OTP memory, where the eventual owner of the device will be unable to change it, and also warns that the GPLv3 will prevent you from following some of its advice. It isn't about legitimate security at all, but rather about DRM that it tries to make sound like a good thing by pretending it's security.
Re: Learn how to design and defend an embedded Linux device
#5This article recommends that manufacturers put the Secure Boot public key in OTP memory, where the eventual owner of the device will be unable to change it, and also warns that the GPLv3 will prevent you from following some of its advice. It isn't about legitimate security at all, but rather about DRM that it tries to make sound like a good thing by pretending it's security.
I had a similar reaction to this. I don't see what the use is in ensuring the hardware is running software from "trustworthy" persons, especially when the device's owner is not usually considered to be part of that group. This feels like something we aught to question, why is it acceptable that even after buying some electronic device there's a part of it that the owner isn't allowed to touch? Embedded devices are just smaller and more focused versions of general-purpose desktop computers, and the latter has been operating just fine now allowing owners to run whatever code they want.
Re: Learn how to design and defend an embedded Linux device
#6This article is not about security. It's about device lock in, so the user will need to jailbreak the device to have control.
IMHO, tiviozation of devices should be banned by law. Currently, GPL3 forbids it only, so, please, use GPL3 for your new open source project.
Re: Learn how to design and defend an embedded Linux device
#7This article is not about security. It's about device lock in, so the user will need to jailbreak the device to have control. IMHO, tiviozation of devices should be banned by law. Currently, GPL3 forbids it only, so, please, use GPL3 for your new open source project.
Please use the AGPL (3), which also defends against SaaSS. (Legitimate SaaS providers can still use it.)
Re: Learn how to design and defend an embedded Linux device
#8This article is not about security. It's about device lock in, so the user will need to jailbreak the device to have control. IMHO, tiviozation of devices should be banned by law. Currently, GPL3 forbids it only, so, please, use GPL3 for your new open source project.
Please use the AGPL (3), which also defends against SaaSS. (Legitimate SaaS providers can still use it.)
It doesn't stop providers from hosting it unmodified, or with modifications that they don't care about releasing—that's why Mongo switched from it, because other providers just provided hosting for it unmodified.
Re: Learn how to design and defend an embedded Linux device
#9A question very marginally related to embedded Linux, but is there any way to do hard real time on Linux? I'm working on an embedded project that requires it, and while its achievable with microcontrollers and embedded Rust, it would just be so much easier if I had an actual OS.
Re: Learn how to design and defend an embedded Linux device
#10A question very marginally related to embedded Linux, but is there any way to do hard real time on Linux? I'm working on an embedded project that requires it, and while its achievable with microcontrollers and embedded Rust, it would just be so much easier if I had an actual OS.
ive not done hard real time for a number of years (usually I have foubd its not needed), but Xenomai would be one option for real hard realtime. The other option is to use the rtlinux patches, however that is not true hard real time, but for most use-cases works ok.