linux-kernel - Re: Turris Omnia firmware possibilities [Was: Re: led: hw-trigger, global brightness and multi-colored leds]

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 25 May 2018 16:02:27 +0200
From:   Tomas Hlavacek <tomas.hlavacek@....cz>
To:     Uwe Kleine-König <uwe@...ine-koenig.org>
Cc:     Jacek Anaszewski <jacek.anaszewski@...il.com>,
        Pavel Machek <pavel@....cz>, linux-kernel@...r.kernel.org
Subject: Re: Turris Omnia firmware possibilities [Was: Re: led: hw-trigger,
 global brightness and multi-colored leds]

On Fri, May 25, 2018 at 8:08 AM, Uwe Kleine-König <uwe@...ine-koenig.org> wrote:
> Hello Tomas,
>
> On 05/25/2018 12:08 AM, Tomas Hlavacek wrote:
>> But I also have good news: The FW of the MCU is also OSS (see the repo
>> in the link (1)). There is a method for flashing the MCU over I2C from
>> Linux and there is JTAG connector for the MCU, in case un-bricking is
>> needed. Therefore the LED protocol can be changed to be more sensible
>> and/or it is even possible to emulate some existing HW LED driver chip
>> in Omnia MCU and reuse OSS driver for that chip.
>
> Yeah, I noticed, but when we start replacing the firmware, we'd need to
> detect somehow when a machine has an old (or only different) firmware.
> That would imply a versioning scheme and a generic way to read out the
> firmware version. (CMD_GET_FW_VERSION_BOOT is already a start, but this
> doesn't help me if I find an unknown hash.) So a CMD_GET_FW_SOMETHING
> that yields a version string that is similar to the soname of a library
> would be great.

Oh yes, I was actually trying to push rewrite of the FW before the
production started, but it looked like a redundant work and I rather
implemented the mentioned rule-breaking LED driver. Another good news
is that all the produced boards had the same FW image and there were
no (official and automated) updates so far. I think that in this
situation it is possible to re-write the firmware it if proves to be
the best solution for LED driver and fixing other glitches perhaps.
The only thing we need regarding versions we need is to either check
that we are upgrading the original version and/or consent from the
user to rewrite any other version that we might encounter. (If there
are some user-customized boards around.)

>
> Talking about firmware, I wonder if there is firmware supported needed
> to solve
> https://wiki.debian.org/InstallingDebianOn/TurrisOmnia#Power_Management
> . Didn't look into that deeply yet and probably not high prio given that
> normally the Turris Omnia will just run 7x24h.

That's right, there is no power-down signalization from the CPU right
now. Btw. is there any mechanism in kernel to signal over arbitrary
bus (like I2C) that the host is shutting down and the power can/should
be cut to CPU in N seconds?

Tomas