search

Start9Labs / start-os

Open source Linux distro optimized for self-hosting
https://start9.com
MIT License
958 stars 89 forks source link

[feat]: Allow (Specified) Hardware Access To/From a Service Container #1440

Open kn0wmad opened 2 years ago

kn0wmad commented 2 years ago

Prerequisites

Describe the Feature Request

A service that requires access to specific hardware, such as a usb device, needs the ability to access it from the container. This may or may not be a good idea, and this ticket is to discuss viability and pros/cons.

Describe the Use Case

This obviously carries security implications, but some developers would like to make use of, for example, a USB device with their service.

Describe Preferred Solution

No response

Describe Alternatives

No response

Anything else?

No response

chrisguida commented 2 years ago

Can you list some use cases?

kn0wmad commented 2 years ago

Hardware wallets is the example that prompted the ticket, perhaps controlling a battery backup or other critical infrastructure that may not have network/internet connectivity

chrisguida commented 2 years ago

Wouldn't it be pretty useless to hook up a hw wallet to the embassy? You'd want it connected to the client device, not the server, right?

kn0wmad commented 2 years ago

That's what I will always do, but some services would require this, as stated. CKBunker is one. I'm not arguing for this, I'm presenting the ticket as it has come up and it needs to be determined if this is a good idea.

chrisguida commented 2 years ago

Ok, so it looks like ckbunker is one use case, since its explicit purpose is to allow tx signing without physical access to the coldcard. So we'll definitely need this if we want ckbunker. It's cool software, the question is: is it cool enough to make this feature worth building

kn0wmad commented 2 years ago

Ok, so it looks like ckbunker is one use case, since its explicit purpose is to allow tx signing without physical access to the coldcard. So we'll definitely need this if we want ckbunker. It's cool software, the question is: is it cool enough to make this feature worth building

I mentioned this in my last comment and the original ticket asked if this feature was worth implementing or not, for practicability and security reasons

AndySchroder commented 1 year ago

Distributed Charge (http://andyschroder.com/DistributedCharge/) and Board A0 (http://andyschroder.com/DistributedCharge/BoardA0/Overview/) could benefit from special I/O hardware access via a container on the raspi4.

For example, here's some special hardware access needed:

$ ll /dev/ttyAMA1 /dev/spi* /dev/gpiomem /dev/i2c*
crw-rw---- 1 root gpio    239,  0 Jul 21  2021 /dev/gpiomem
crw-rw---- 1 root i2c      89,  1 Jul 21  2021 /dev/i2c-1
crw-rw---- 1 root spi     153,  0 Jul 21  2021 /dev/spidev1.0
crw-rw---- 1 root dialout 204, 65 Nov 20 14:11 /dev/ttyAMA1
$

It would be nice if these devices would be allowed to be referenced using the devices: parameter in docker compose files or the --device option when using docker run (I'm not sure exactly how you setup a container in embassy).

Also, would be nice to have network_mode: host so that raw network devices can be accessed. SocketCAN (https://docs.kernel.org/networking/can.html) uses raw network devices and not TCP. For example, Distributed Charge - EV needs can0 and can1 to operate:

$ ip addr|grep can
3: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP group default qlen 10
    link/can
4: can1: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP group default qlen 10
    link/can
$
kn0wmad commented 1 year ago

Distributed Charge (http://andyschroder.com/DistributedCharge/) and Board A0 (http://andyschroder.com/DistributedCharge/BoardA0/Overview/) could benefit from special I/O hardware access via a container on the raspi4.

Whoa, really cool projects, @AndySchroder!! I assume you have already considered applications for home systems as well? (EDIT: disregard, I just saw the GRID section of your website - so fucking cool!!)

Start9 has a keen eye on all the aspects of this project (Bitcoin, IoT, Energy, Automation, Sovereignty), and it fits in nicely with our vision of the future. Pumped to see this develop!!

AndySchroder commented 1 year ago

Thanks! Yes, GRID could work for a home, the mechanical packaging is just setup for an industrial setting now and would need to be customized for a home instead.

Also, unrelated, but you should check out my general purpose bitcoin node build: http://andyschroder.com/DistributedCharge/news/2022.06.04-RaspiBlitzOnTheTOFU/ . I'd like to also test out embassy OS on there as well. I think it should work just fine.

chrisguida commented 1 year ago

Seems we could implement this as devices: in the manifest?

kn0wmad commented 1 year ago

Thanks! Yes, GRID could work for a home, the mechanical packaging is just setup for an industrial setting now and would need to be customized for a home instead.

Also, unrelated, but you should check out my general purpose bitcoin node build: http://andyschroder.com/DistributedCharge/news/2022.06.04-RaspiBlitzOnTheTOFU/ . I'd like to also test out embassy OS on there as well. I think it should work just fine.

Very cool, I imagine it would work - if you test it out and get a successful install, please let us know so we can add it to our 'known good' hardware list - feel free to join our community forum there too, we love seeing what people are hacking on!!