- Malcolm XML
- Aug 8, 2009
-
I always knew it would end like ｔｈｉｓ．
|
whats your threat model
no threat model = defending against nothing
Currently I am working on making our embedded product secure. Here are some steps I am taking to do so:
System:
SELinux: Set to enforcing.
Custom SELinux contexts for our program.
A custom kernel HAL layer for talking to the hardware.
A user space application to talk to the HAL layer.
A OTP key in the processor die that our software authenticates against, if it doesn't find it then the software won't work.
All flashing is done in house.
Root is disabled.
Web interface:
We are using nginx with the nasxi module, php7, and fcgi, all with appropriate custom SELinux contexts.
The user password is set to the company name, but the software will require the user to change the password before the product works.
Of course all passwords are hashed and salted via bcrypt (is there something better?).
Unfortunately many of our customers still want telnet, so I have to include it, but it's turned off by default and a gigantic warning will pop up on the screen telling end users that the trafic isn't encrypted and that we strongly advise people to use ssh instead.
Anything else I am missing or could do better?
|
#
¿
Sep 2, 2016 23:46
|
|
- Adbot
-
ADBOT LOVES YOU
|
|
|
#
¿
May 16, 2024 09:25
|
|
- Malcolm XML
- Aug 8, 2009
-
I always knew it would end like ｔｈｉｓ．
|
I have been meaning to write a embedded Linux op for quite some time, but I have been too lazy or just plain forgot, but no more!
My background
I started out messing around with Linux 16 years ago with Slackware 7.1, and used it as my primary operating system ever since.
In 2010 I was unemployed and fixing cars in my garage while going to college when I was called up randomly by a friend I hadn't seen in a few years. His boss who ran a tiny engineering company (2 employees and himself) had just picked up/inherited a camera project. This particular camera ran embedded Linux off of a TI DM368 processor and they needed help getting Linux up and running on it, and I was the only "Linux guy" he knew. I was told I was only going to be needed for a few weeks. That job lasted 4 and a half years.
In those 4 and a half years I learned how to program starting with C, how to write kernel drivers, board layout, the basics of electronics, power management, project management, system architecting, and so on; basically how a product goes from concept to the shelf. During my tenure at that company I completed 3 finished projects including a Android tablet before our main client hosed over my boss and tanked his little engineering company.
6 Months later I moved halfway across the United States to Michigan to continue my career. My current project is working on a SIP phone, with my main focus on creating a incredibly flexible embedded distribution based off of buildroot with a huge focus on security.
Linux Vs RtOS
There are several reasons one should choose embedded Linux over a RtOS.
- The Linux Kernel:
The Linux kernel provides a incredibly rich feature set that gives the developer a absolutely enormous amount of support for tons of common hardware components and features, including a FULLY FEATURES AND STABLE NETWORK STACK.
- A ever growing amount of development boards.
Wand ultra cheap? Raspberry Pi being the most popular
Need Emmc? Beagle Bone black is for you!
Like Freescale (now nxp?) I like the wandboard, Boundarydevices is also great
- Feature rich SDK's
The three major ones I know of are:
Buildroot
Yocto
Ptxdist
I am a contributor to buildroot, and I am familiar as well with ptxdist. I need to someday learn yocto.
- Major distributions work on many embedded platforms as well!
Ubuntu, fedora, Gentoo, Arch, CentOS/RHEL and many more all have builds that work on many popular embedded devices.
Why does this thread exist?
I think this thread could be useful for many people getting started or even asking more advanced questions about the embedded Linux world. I will try to post any neat stuff I am doing that isn't covered under my NDA as well.
Feel free to tell me I missed something/ask me questions!
in actual questions, i wanna modulate an ASK 433mhz thing with pretty precise microsecond timing. does linux have a "treat this thread as real-time" like windows
|
|
#
¿
Sep 2, 2016 23:49
|
|
- Malcolm XML
- Aug 8, 2009
-
I always knew it would end like ｔｈｉｓ．
|
OK re security, so your model is corp espionage. What modes of attack are you looking at? Full device access? I mean that's essentially impossible to deal with unless youre gonna go real deep and blow fuses and stuff, have designed ur board to avoid leaking info in side channel attacks like differential power analysis, thermal analysis, decapping etc. If it's just SW access, then yeah u need to limit any access that's not needed by the software to the bare minimum, disable all unnecessary services, ensure authentication by all accesses, etc
OK so for the process i can just pin it to a core and set the scheduler policy so that that process is the only thing on the core. Works for me!
|
|
#
¿
Sep 7, 2016 17:10
|
|
- Malcolm XML
- Aug 8, 2009
-
I always knew it would end like ｔｈｉｓ．
|
good for you! As for buildroot? https://buildroot.org/downloads/manual/manual.html
But the gist of it is:
download buildroot
make raspberrypi_defconfig
make
Then flash the output in "output/images" to a SD card and boot.
As for you wanting to access a driver via userspace? Depends on what your driver DOES.
The common way for a new guy to do so is via a gpio call in /sys/class/gpio
http://elinux.org/CI20_GPIO_LED_Blink_Tutorial
The second way is to create a /sys/ device and shove folders and files in there, although for a simple device setup I wouldn't do that.
Another way is to create a /dev/ device and talk to it that way.
linux has a SPI driver and it's a device tree overlay away in raspbian, so no dicking with kernel drivers (u dont want to, its a PITA)
http://www.haifux.org/lectures/258/gpio_spi_i2c_userspace.pdf
|
|
#
¿
Sep 7, 2016 17:14
|
|
- Malcolm XML
- Aug 8, 2009
-
I always knew it would end like ｔｈｉｓ．
|
I'm glad you asked!
We have taken device access in consideration and have implemented a OTP key into the die of the processor which our software authenticates with. If it doesn't find that key the software itself refuses to run. The FS itself is R/O and encrypted as well. As for power analyses, not much I can do there.
GPIO also has a standard sysfs overlay you can tinker with.
cool, but like, what kind of adversary we talking about, it's not exactly unknown to literally acid etch off encapsulation and count 1's and 0's in ROM (http://zacsblog.aperturelabs.com/2013/02/decapping-integrated-circuits-using.html)
i once knew a guy who did SEM/TEM scans of HDDs for forensics, and u can do similar poo poo on NAND: http://proceedings.spiedigitallibrary.org/proceeding.aspx?articleid=1555687
might wanna ask here for SW help beyond the standard principle of least privilege: http://forums.somethingawful.com/showthread.php?noseen=0&threadid=3500975&perpage=40&pagenumber=42#pti15
|
|
#
¿
Sep 8, 2016 00:49
|
|
- Malcolm XML
- Aug 8, 2009
-
I always knew it would end like ｔｈｉｓ．
|
i had find some time to get vagrant because i'm on a mac, but now make's taking care of business on my stock raspberry pi image...
i'm confident that i can make a test program go out and talk to a SPI device and will do that before diving in further. i mentioned kernel drivers because i'm trying to give myself a crash course in the field. i've written microcontroller drivers for SPI chips that require rapidly servicing interrupts, e.g. relatively decent ADCs for an application that requires samples not be dropped. i was planning on going through the linux device drivers book to try to recreate something like that in this environment. i know it's not an RTOS, but i imagine my raspberry pi doing nothing else is up to the task and this sort of thing is all in a day's work for an embedded linux dev. sound feasible?
would this be the sort of task an intermediate level developer would be expected to be doing? what else should i make sure i get familiar with?
Here's the spi driver for the bcm chip in the rpi: http://lxr.free-electrons.com/source/drivers/spi/spi-bcm2835.c
bcm2835 lib will give you the constants for enabling DMA access to the HW, but only as root to get direct access to the MMIO registers via /dev/mem
It's pretty mechanical and not that interesting tbh
Malcolm XML fucked around with this message at 00:59 on Sep 24, 2016
|
|
#
¿
Sep 24, 2016 00:51
|
|
- Adbot
-
ADBOT LOVES YOU
|
|
|
#
¿
May 16, 2024 09:25
|
|
- Malcolm XML
- Aug 8, 2009
-
I always knew it would end like ｔｈｉｓ．
|
conveniently someone's done the hard work: http://lkml.iu.edu/hypermail/linux/kernel/1608.0/00558.html
|
|
#
¿
Sep 29, 2016 14:40
|
|
#
¿
Sep 2, 2016 23:46
