[Trisquel-devel] RISCV T-Head CPU bug and Trisquel riscv64 port

[Simon Josefsson]

Jing Luo <jing at jing.rocks> writes:

> Hello all,
>
> About two days ago, researchers published a sever CPU bug "ghostwrite"
> in T-Head C910 and C920 CPU's vector extension. The CPU bug is 
> unpatchable by software, allows arbitrary memory write of *physical
> address*. The only work around is to disable the vector extension in
> the device tree (?), but with a significant performance penalty of
> 30~%.
>
> https://ghostwriteattack.com/riscvuzz.pdf
>
> I was going to buy the Milk-V Pioneer board (affected by the bug) and
> I had plan to make it a pure build farm, running VMs for Trisquel and
> gcc compile farm, etc. I even had it in my shopping cart, waiting for
> the foreign exchange rate to drop so I could buy it. Now, I don't
> think it is suitable for hosting anymore. I know Simon has one Pioneer
> board; WDYT? Can someone else convince me "the bug is not that
> serious"?

For a build host, I don't think it is a deal-breaker: if something is
polluting the binaries that are built -- via CPU bugs or some other
attack vector -- we should catch that by rebuilding packages elsewhere
and producing diffoscope output of differences compared to the official
packages.  Admittedly, nobody does this today for Debian or Ubuntu
either, but that just means we are not worse than anyone else anyway.

If we notice serious problems, rebuilding the packages and publishing
the new version will always be possible.  This isn't too different from
other security problems, its just that it affects the binaries and not
the source code that we are used to review.

I think we would serve the Trisquel community better by ecne having some
possibly sub-optimal riscv port than not having it at all, but it is
reasonable to argue the other way too.

> I do have a Lichee Pi 4A (affected by this bug). Can I help with
> Trisquel's riscv64 port? I can help build packages using sbuild, but 
> IIUC we need to bootstrap from a foreign distro first (Ubuntu) to get
> a working schroot. Maybe I can help with that?
>
> ---
> Anyways, since Simon asked about blobs on the gcc compile farm mailing
> list, if I recommend some boards, I would recommend the mature and 
> reliable VisionFive 2 or the Pine Star64, both based on the same CPU
> Starfive JH7110 which is not vulnerable to this bug. They are not
> really as fast as T-Head C910, but they are inexpensive. You can buy
> like 5 of them for a cluster. VisionFive 2 is already supported by
> mainline linux (since 6.?), Star64 has support since 6.11-rc1, and the
> device tree can be easily backported to 6.8 or 6.9. As for u-boot,
> AFAIK, u-boot itself doesn't ship any blob. I have both of these
> boards, but I haven't test/install them yet.

I have received a SiFive HiFive Unmatched RevB development kit and I
will play with it [when I get some spare time...] to see if it is
simpler to get a debootstrap + linux-libre bootable on it.

Maybe this is a good way to help: identify some blob-free risc-v
hardware, and document how to install Debian using debootstrap plus
linux-libre on it, for use as a Trisquel build host for ecne risc-v
packages.  Once an initial set of packages builds are published, I think
it should be possible to re-install it again to run Trisquel natively
instead of Debian.

/Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 255 bytes
Desc: not available
URL: <http://listas.trisquel.info/pipermail/trisquel-devel/attachments/20240810/7e5af685/attachment.sig>