/dev/i2c-7 messes up non rockpi units

[shawaj]

if you add:

      - /dev/i2c-7:/dev/i2c-7

to a device (such as raspberry pi) that doesn't have this devices on the host-os then it fails to start those containers (diag and miner in this case).

Need to see if we can find a workaround for that

[shawaj]

Possibly privileged: true is the best solution.

Not ideal though so will also reach out to balena

[shawaj]

This has fixed things so it works on both RockPi and RasPi.

The only question is whether there's any detrimental effects of using privileged: true in general

[kashifpk]

privileged containers can be exploited to have full access to the host's devices (Ref: https://blog.trailofbits.com/2019/07/19/understanding-docker-container-escapes/) but in our case should not be an issue as we're using these boards for the single purpose of running the helium miner software. And that too is only possible with some constraints. So if a user that has our boxes wants to exploit this he is just messing with his own hardware. For a remote attacker he would first need someway to get a footprint into the container (via balena or some fault in our code). As we have balena public device urls disabled mostly that shouldn't be an issue.

My 2c - Not that risky considering where we're using it.

[shawaj]

@kashifpk that was my thoughts also.

I guess the alternative is to maintain another repo for the RockPi version of the software but that seems unnecessary given this being the only required difference.

I wonder if it's possible to achieve this with any cap-add directive? Or whether we can make privileged: true more secure using cap-drop?

Also relates to #259 and maybe something like balena contracts or one of the other linked things could be helpful such as using multiple compose files for example https://docs.docker.com/compose/reference/

[vpetersson]

I think it is inevitable that we will have to add multiple docker-compose files. Perhaps a better solution is to simply modify the build script to automatically configure /dev/i2c accordingly. That will unfortunately require us to run on different fleets, but perhaps it is the path of least resistance.

[shawaj]

@vpetersson I think we will have to run on different fleets anyway because of the VARIANT being different on different hardware. We haven't solved that yet and not convinced we can...

[vpetersson]

Yeah we were just discussing this in the stand-up. Then we can just auto-generate the docker-compose.yml file on run time (similar to Balena's Dockerfile.template) and just render it according to the target.

[shawaj]

Perhaps for Testnet we use privileged: true and for other units we use different i2c bus.

Having said that...I don't see any particular reason not to use privileged: true on production devices.

Either way, the tooling isn't terribly difficult whichever path we choose

[vpetersson]

I want to keep the delta between testnet and mainnet minimal. privileged: true is a big one that can cause a lot of different behaviors and bugs to go undiscovered.

[shawaj]

@vpetersson then we have to maintain multiple different testnets as well i.e. RockPi testnet and RasPi testnet

[shawaj]

I wonder if there's a way to remap i2c-7 on RockPi to i2c-1 (and vice versa) but probably more hassle than it's worth and not a good idea / something balena will support as will mean differences between operation on native and balenaOS

[vpetersson]

@vpetersson then we have to maintain multiple different testnets as well i.e. RockPi testnet and RasPi testnet

Yeah good point. I think we should do that.

I wonder if there's a way to remap i2c-7 on RockPi to i2c-1 (and vice versa) but probably more hassle than it's worth and not a good idea / something balena will support as will mean differences between operation on native and balenaOS

Possible, but i think it's more likely they will allow the container to start w/out the device existing tho.

[shawaj]

I suppose one benefit to having different testnets is that we can more easily isolate hardware specific issues

[vpetersson]

Yeah exactly.

[shawaj]

@vpetersson created a PR in #264 to sort this

[marvinmarnold]

Blocked by completion of: #272