[MIR] opensbi

[Summary]
MIR Team nack until the unbundling of libfdt was checked and either done
or reasonably explained why it is undoable + a security ack on the exception
to do so.
Furthermore I'd strongly recommend to add an autopkgtest for it before we
promote it.

Report back here once those are resolved, to get an MIR-Ack and passing it
along to the security team then. Setting the state abck to invalid to reflect
that the action is on the reporter.

Notes:
- if it can't work against libfdt1 from the archive we will need security
  to consider if this is ok as a special case or a no-go.

Required TODOs:
- embedded libfdt is outdated and well, embedded. Please build and link
  against the libfdt1 / libfdt-dev that is in main.

Recommended TODOs:
- Self-tests are essentially non-existent. I'd be slightly scared of breakage
  even due to other components or by the toolchain used on build.
  Could we add a autopkgtest that uses this to boot a minimal riscv system?

[Duplication]
OK:
There is no other package in main providing the same functionality.

[Dependencies]
OK:
- no other Dependencies to MIR due to this
- no -dev/-debug/-doc packages that need exclusion

[Embedded sources and static linking]
OK:
- no static linking in the usual sense. As outlined when filing the result
  are elf object without runtime dependencies to load on boot.
  The one problem in this is libfdt (see below)

Problems:
- embedded source present - libfdt
  This contains, builds and uses a contained libfdt
  This package exists in the archive and in main
   libfdt1 | 1.5.1-1 | focal
   libfdt1 | 1.6.0-1 | groovy
   libfdt1 | 1.6.0-1 | hirsute
  The bundled code is outdated (on 1.5.1 atm).
  Due to being a static link anyway - after a fix of src:device-tree-compiler
  that provided libfdt a rebuild of src:opensbi would be needed anyway.
  But we won't know if fixed are monitored the same way and/or applicable
  to the bundled code.
  The code itself is rather stable, no public API change since 1.2.
  Please try if this can build and (static) link with the in-distro
  libfdt. If we can't it is up to security to decide if that is ok or a problem
  that should be blocked on.

[Security]
OK:
- history of CVEs does not look concerning
- does not run a daemon as root
- does not use webkit1,2
- does not use lib*v8 directly
- does not parse data formats
- does not open a port
- does not process arbitrary web content
- does not use centralized online accounts
- does not integrate arbitrary javascript into the desktop
- does not deal with system authentication (eg, pam), etc)

Problems:
- as outlined by the reporter this runs in the highes possible privilege
  mode. Combined with the issues around libfdt I'd recommend security having
  a look.

[Common blockers]
OK:
- does not FTBFS currently
- The package has a team bug subscriber
- no translation present, but none needed for this case (user visible)?
- not a python/go package, no extra constraints to consider int hat regard
- no new python2 dependency

Problems:
- does not have a test suite that runs at build time
- does not have a test suite that runs as autopkgtest
  Since Risc is emulated anyway this should wor...

Required TODOs:
- embedded libfdt is outdated and well, embedded. Please build and link
  against the libfdt1 / libfdt-dev that is in main.

Cannot do =)

opensbi is firmware. It runs in a different RISC-V mode - machine, not user. This code is compiled freestanding, without pic/pie, without stack protection, and without requirement to have libc. One can notice that there is an libfdt_env.h header to remap functions that look like standard ones (memcpy and the like).

It would be nice if I could build-depend on libfdt-dev source package + built-using. That way any CVEs would leave enough breadcrumbs to follow.

But this is no different to how grub2 vendorizes lzo, gcrypt, and a few other things. All of which is rebuilt freestanding. So at best I can notify security team to add an embedded source copy mapping.

W.r.t. being out of date I see that upstream did import 1.5.1 but not 1.6.0. I can work with them to update to 1.6.0 at least.

> Required TODOs:
> - embedded libfdt is outdated and well, embedded. Please build and link
> against the libfdt1 / libfdt-dev that is in main.
>
> Cannot do =)
>
...
Thanks for the explanation why even a normal static link won't work here.
I didn't think about it Firmware'ish execution in that regard.

> It would be nice if I could build-depend on libfdt-dev source package +
> built-using. That way any CVEs would leave enough breadcrumbs to follow.
>
Yeah some trick like that, but I can see that this won't work easily.
>
> But this is no different to how grub2 vendorizes lzo, gcrypt, and a few
> other things. All of which is rebuilt freestanding. So at best I can
> notify security team to add an embedded source copy mapping.

Your explanation is fine, we will only want Security to "sign off" on
it which usually
means they will establish such a not to track it correctly.

> W.r.t. being out of date I see that upstream did import 1.5.1 but not
> 1.6.0. I can work with them to update to 1.6.0 at least.

Being outdated wasn't too much of an issue (as it isn't too old).
It was more an FYI on that as an example what the embedded lib might miss.
No need to action on this one.

But the tests would still be interesting - do you think this could get
a reasonable autopkgtest or would that be more pain than gain?

P.S. Assigning to security for evaluation

FYI, the update to libfdt got accepted upstream, so next release will have up to date vendored library.

In terms of testing: it should be possible to write an autopkgtest that boots a small VM. That would test the "elf" loaders for the"generic" platform.

The fu540 platform however will need testing on baremetal using the daily images. I wonder if we can automate that with testflinger somehow.

I reviewed opensbi 0.9-1ubuntu3 as checked into hirsute. This shouldn't be
considered a full audit but rather a quick gauge of maintainability.

opensbi is a firmware for riscv-based systems. It executes outside of
operating systems, in order to provide services necessary for bootloaders,
hypervisors, etc.

- CVE History:
  - no cves in our database
- Build-Depends?
  - gcc-riscv64-linux-gnu, debhelper-compat
- pre/post inst/rm scripts?
  - none
- init scripts?
  - none
- systemd units?
  - none
- dbus services?
  - none
- setuid binaries?
  - none
- binaries in PATH?
  - none
- sudo fragments?
  - none
- polkit files?
  - none
- udev rules?
  - none
- unit tests / autopkgtests?
  - I didn't see anything useful
- cron jobs?
  - none
- Build logs:
  - clean

- Processes spawned?
  - none
- Memory management?
  - Looked careful
- File IO?
  - none
- Logging?
  - very little, looked fine
- Environment variable usage?
  - none
- Use of privileged functions?
  - not posix privileged functions, but rather privileged CPU instructions
- Use of cryptography / random number sources etc?
  - none
- Use of temp files?
  - none
- Use of networking?
  - none
- Use of WebKit?
  - none
- Use of PolicyKit?
  - none

- Any significant cppcheck results?
  - only false positives
- Any significant Coverity results?
  - unavailable
- Any significant shellcheck results?
  - nothing important
- Any significant bandit results?
  - none

This is highly complex software, but it's fairly straightforward C,
programmed carefully. I opened two issues for things I found, but wouldn't
be surprised if they both get closed as not-a-bug.

Security team ACK for promoting opensbi to main with the caveat that we
have no hardware, no way to test our updates without help, and will be in
the position of publishing updates -- or *not* publishing updates -- based
entirely on upstream's recommendations and support.

We will need help from foundations in the event of updates.

https://github.com/riscv/opensbi/issues/201
https://github.com/riscv/opensbi/issues/202

Thanks

Thanks, this already shows up in component mismatches - threfore setting the state to Fix Committed.
This is waiting for an AA to promote the package.

Override component to main
opensbi 0.9-1ubuntu3 in hirsute: universe/misc -> main
opensbi 0.9-1ubuntu3 in hirsute amd64: universe/misc/optional/100% -> main
opensbi 0.9-1ubuntu3 in hirsute arm64: universe/misc/optional/100% -> main
opensbi 0.9-1ubuntu3 in hirsute armhf: universe/misc/optional/100% -> main
opensbi 0.9-1ubuntu3 in hirsute i386: universe/misc/optional/100% -> main
opensbi 0.9-1ubuntu3 in hirsute ppc64el: universe/misc/optional/100% -> main
opensbi 0.9-1ubuntu3 in hirsute riscv64: universe/misc/optional/100% -> main
opensbi 0.9-1ubuntu3 in hirsute s390x: universe/misc/optional/100% -> main
8 publications overridden.