Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Learn how to design and defend an embedded Linux device

embeddedbits.org

Post reply on HN
Print view View original

11–20 of 36 posts

Re: Learn how to design and defend an embedded Linux device

#11

Post by jdsnape »

malwrar wrote: post #5
josephcsible wrote: post #4

This 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 ju…

I agree with you for devices where the user should be considered 'trusted' - I like to tinker too.

But I think there are use-cases where this is legitimate, for example, ticket readers mounted on public transport where anyone could tamper with them out-of-hours, or a utility meter installed in my house where I might want to change the way it records consumption to get out of paying. Likewise, a payment terminal taking card payments in a restaurant - as a diner I'd quite like some assurance that someone couldn't tamper with it to record card details for example.

Re: Learn how to design and defend an embedded Linux device

#12

Post by DenseComet »

mlaretallack wrote: post #10
DenseComet wrote: post #9

A 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.

Interesting, thank you! I'll take a look at Xemomai, but it seems like the options are very limited. I'm building a TVC rocket, so hard real time is unfortunately a strict requirement.

Re: Learn how to design and defend an embedded Linux device

#13

Post by tpxl »

jdsnape wrote: post #11
malwrar wrote: post #5

Earlier quoted context omitted.

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 ju…

I agree with you for devices where the user should be considered 'trusted' - I like to tinker too. But I think there are use-cases where this is legitimate, for example, ticket readers mounted on public transport where anyone could tamper with them out-of-hours, or a utility meter installed in my house where I might want to change the way it records consumption to get out of paying. Likewise, a payment terminal takin…

A random third party owning the trust root doesn't help you in any of those situations.

Re: Learn how to design and defend an embedded Linux device

#14

Post by R0b0t1 »

DenseComet wrote: post #9

A 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.

Yes, there's nothing more challenging about using Linux for hard realtime. You still need to address your IO to ensure realtime constraints but you have the benefit of already constructed realtime ethernet drivers, etc.

It's also common to run your code as init and avoid calling into the kernel.

A more modern treatment is to write whatever and then qualify the system thoroughly, and all things considered this will probably overtake everything else as the main development methodology.

Re: Learn how to design and defend an embedded Linux device

#15

Post by joezydeco »

DenseComet wrote: post #9

A 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.

A numbers of SoC makers have adapted by adding M4 or M7s as real-time coprocessors to the main application core. There's also the TI Sitara (Beaglebone) with its PRU that can function as a real-time assist.

Re: Learn how to design and defend an embedded Linux device

#16

Post by zozbot234 »

DenseComet wrote: post #9

A 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.

The wiki for the PREEMPT_RT patchset has a general HOWTO: https://rt.wiki.kernel.org/index.php/HOWTO:_Build_an_RT-appl...

Generally speaking, your limiting factor wrt. hard RT performance is going to be the underlying hardware, not the OS per se. This of course assumes that you avoid known sources of OS-related latency.

Re: Learn how to design and defend an embedded Linux device

#17

Post by Gibbon1 »

DenseComet wrote: post #12
mlaretallack wrote: post #10

Earlier quoted context omitted.

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.

Interesting, thank you! I'll take a look at Xemomai, but it seems like the options are very limited. I'm building a TVC rocket, so hard real time is unfortunately a strict requirement.

I think you can do hard real time inside drivers. The other is some embedded linux capable chips have TPU's, aka Time Processing Units.

For something like a thrust vectoring rocket, I'd stick to a sub processor running an actual RTOS or bare metal code.

Re: Learn how to design and defend an embedded Linux device

#18

Post by CameronNemo »

josephcsible wrote: post #4

This 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.

Is there a way to implement secure boot for embedded devices in another way? I've been racking my brain and the only way I can think of is to have a flash of an image verification key also result in an on device regeneration of a private key. Then require the device to sign something with that private key to verify the boot. All of that would require a complicated boot process and probably an embedded controller to facilitate.

Re: Learn how to design and defend an embedded Linux device

#19

Post by elcritch »

jdsnape wrote: post #11
malwrar wrote: post #5

Earlier quoted context omitted.

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 ju…

I agree with you for devices where the user should be considered 'trusted' - I like to tinker too. But I think there are use-cases where this is legitimate, for example, ticket readers mounted on public transport where anyone could tamper with them out-of-hours, or a utility meter installed in my house where I might want to change the way it records consumption to get out of paying. Likewise, a payment terminal takin…

It's a conundrum. I prefer to have devices that are open to user modification or fixes, but that inherently means bad actors could also readily modify the device. Though even devices locked with DRM can be rooted, so perhaps it's a false sense of security.

It'd be great if one could build on zero knowledge proofs with something like monero that could let you verify the firmware of a device. Or rather, your phone/credit card queries the device with a ZKP (or something), then uses a public blockchain to verify the devices firmware signature chain. A user could possibly then use a "adblock" like software to warn of manufacturers that have been breached, etc.

Re: Learn how to design and defend an embedded Linux device

#20

Post by jlokier »

tpxl wrote: post #13
jdsnape wrote: post #11

Earlier quoted context omitted.

I agree with you for devices where the user should be considered 'trusted' - I like to tinker too. But I think there are use-cases where this is legitimate, for example, ticket readers mounted on public transport where anyone could tamper with them out-of-hours, or a utility meter installed in my house where I might want to change the way it records consumption to get out of paying. Likewise, a payment terminal takin…

A random third party owning the trust root doesn't help you in any of those situations.

Yes it does, because it's not a random third party.

It's the device manufacturer.

Everyone is already dependent on some level of integrity by the device manufacturer, whether they're happy with this or not, because there is no other option.

That integrity might be checked. The manufacturer may be audited. Their processes and people may be background checked. Their hiring practices subject to a standard. Some of their devices may be selected at random, scrutinised, picked apart, checked by third parties, just to be sure. It's not done much, but perhaps it should be. Anyway, if that's done there is some higher level of justification in trusting the manufacturer's integrity, even if it remains a weak point.

If we already have to trust the device manufacturer and/or their auditors, that makes them owning the software trust root a very different proposition compared with anyone else owning it.

Post reply on HN