Hands-On: MNT Reforms The Laptop
By Kerry Scharfglass, August 26, 2021
- https://hackaday.com/2021/08/26/hands-on-mnt-reforms-the-laptop/

"When we met our contact from MNT in the coffee shop, he was quietly
working away on his laptop. Jet black and standing thick it was
like an encyclopedia that didnt quite blend in with the sea of
silver MacBook lookalikes on the surrounding tables. After going
through all the speeds and feeds we eagerly got our 64 piece driver
kit out to open it up and see what made this marvel tick, but when
the laptop was turned over it became clear that no tools were
needed. The entire bottom of the machine was a single rectangle of
transparent acrylic revealing everything from sharp white status
LEDs on the bare mainboard to individual 18650 LiFePO4 battery
cells in a tidy row. In a sense thats the summary of the entire
product: its a real laptop you can use to get work done, and every
element of it from design to fabrication is completely transparent.
The device pictured here is called the Reform and is designed and
manufactured by MNT, a company in Berlin, Germany (note MNT stands
for MNT, its not an acronym). The Reform is a fully open source
laptop which is shipping today and available via distribution
through Crowd Supply. If the aesthetic doesnt make it clear the
Reform is an opinionated product designed from the ground up to
optimize for free-as-in-freedom: from its solid metal chassis to
the blob-free GNU/Linux distribution running inside.
Were here to tell you that weve held one, its real, and its very
well built." ...

--
__ __
#_ < |\| |< _#

In comp.misc, Computer Nerd Kev <not@telling.you.invalid> wrote:
> Hands-On: MNT Reforms The Laptop
> By Kerry Scharfglass, August 26, 2021
> - https://hackaday.com/2021/08/26/hands-on-mnt-reforms-the-laptop/

Looks nice, but not cheap. (Which is what I expected, really.)
$1500ish for an assembled machine with no wifi card or ssd (includes
connectors for bring your own). $1000ish for an assemble-yourself
version of that. I like the think-pad-ish look and the ~12" screen
size. ARM and 4GB of RAM are drawbacks. The standard-off-the-shelf
battery option is very nice, the trackball option is intriguing.
Must be chonky to have room, chonky is not bad but needs noting.

Elijah
------
open source hardware is getting much closer to perfectly reasonable

Eli the Bearded <*@eli.users.panix.com> writes:

> open source hardware is getting much closer to perfectly reasonable

I guess it depends on how much closed source software this has, if
any. Looks like the hackaday comments say none but that probably goes
out the window with any radio. Oh, with an external display too.

CPU performance vice this is something like a Raspberry Pi 3 with the
Cortex A53 cores. Faster storage and more RAM though, no idea what the
GPU on this can do.

But really, no mic, no bluetooth (or maybe if there's a compatible
wifi+bluetooth card?) And slow.

I'd be interested in an open computer like this though, to be used as a
router. Needs more ethernet ports and a different case for that though.

Eli the Bearded <*@eli.users.panix.com> wrote:
> open source hardware is getting much closer to perfectly reasonable

What I find interesting about this is not the spec, which is pretty run of
the mill, but the enclosure.

Back in the day (~2000s) the problem with a DIY laptop project was the case.
You could design a PCB with the right chips on it, no problem. But your
options for the case were limited.

What you really wanted as injection moulding, but tooling cost $$$$$ unless you
were making tens of thousands of units. So people came up with various
handcrafted things in wood, metal, Lego... but they were strictly one-off
units. There wasn't really anything you could make in volume of say
100-1000.

Nowadays you have 3D printing and laser cutting which scale better, but
nobody really wants a 3D printed laptop (at least with cheap 3D printing
tech) because it isn't robust enough. Likewise you /can/ laser cut a case
from flat sheets, but again it's not very good as a case.

So what's interesting about this is they're CNC milling the case and it
looks pretty good. Hard to tell for sure without decent side view shots
(which are lacking from the review), but it's interesting to see that a case
can be CNCed in small volumes at reasonable cost.

Theo

Anssi Saari <as@sci.fi> wrote:

> But really, no mic, no bluetooth (or maybe if there's a compatible
> wifi+bluetooth card?) And slow.

No microphone and no camera is an intentional design choice, because
people don't really trust those devices not to be covertly activatable.

The problem with faster processors like Intels these days is that you have
to be able to disable the "management engine", ie. built-in coprocessor
with its own software beyond your control. I think Purism does that with
their newer machines, after much research into the subject.
--
/* * * Otto J. Makela <om@iki.fi> * * * * * * * * * */
/* Phone: +358 40 765 5772, ICBM: N 60 10' E 24 55' */
/* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki */
/* * * Computers Rule 01001111 01001011 * * * * * * */

Anssi Saari <as@sci.fi> wrote:
> Eli the Bearded <*@eli.users.panix.com> writes:
>
>> open source hardware is getting much closer to perfectly reasonable
>
> I guess it depends on how much closed source software this has, if
> any. Looks like the hackaday comments say none but that probably goes
> out the window with any radio. Oh, with an external display too.

For the radio, there's the OpenWiFi project. It's not cheap or
convenient but the GitHub page suggests that it's working:
https://github.com/open-sdr/openwifi
https://www.rtl-sdr.com/openwifi-open-source-fpga-and-sdr-based-wifi-implementation/

> CPU performance vice this is something like a Raspberry Pi 3 with the
> Cortex A53 cores. Faster storage and more RAM though, no idea what the
> GPU on this can do.

It _sounds_ like the GPU might be better supported in Linux than
the Raspberry Pi one. I would have liked to see it use a Pi 4
Compute module for easier availability of future upgrades, which
I'd prioritise above open-source personally. The module they're
using is something of an equivalent to that though, the latest
in a line of CPU/RAM boards made by a company that targets
industrial applications (sorry, forgot the name, too lazy to find
the page where they say it again).

> But really, no mic, no bluetooth (or maybe if there's a compatible
> wifi+bluetooth card?) And slow.

Which is all fine for me actually. The price and ARM architecture
are roadblocks though. It actually has a second 32bit ARM processor
described in the specs as unused. I'd be interested in the idea of
setting that up running an emulated x86 Linux system, also with
WINE installed. Equally you could probably do that on a core of the
main CPU, only using the "spare" CPU would be ideal because you
wouldn't sacrifice normal performance. The emulated system would be
slow for sure, but possibly fast enough for the few cases where it's
required (eg. driver software, old/simple applications).

> I'd be interested in an open computer like this though, to be used as a
> router. Needs more ethernet ports and a different case for that though.

http://wiki.banana-pi.org/Banana_Pi_BPI-R2
https://openwrt.org/toh/sinovoip/banana_pi_r2

Schematics are available, though I'm not sure if they're riddled
with important omissions like the RPi ones. I've talked myself out
of buying one of those a few times now. :)

As far as open-source computer hardware goes, I feel it's always
some sort of compromise unless the CPU chip itself is open-source.
It soon becomes a question of at what level you care about the
openness of the design? CPU design? CPU microcode? SoC design? SoC
peripheral firmware/s? Circuit board design? Software?

You can use a RISC CPU, or even now implement a 486 in an FPGA,
run Linux on it and you tick all the boxes. But then you've got
much greater problems with performance and software compatibility
than with the ARM Cortex, besides cost.

Then again the RISC-V systems might not be so far off ARM with
these sorts of boards promised soon:
https://liliputing.com/2021/08/a-risc-v-single-board-pc-is-coming-soon-from-radxa-and-starfive.html

--
__ __
#_ < |\| |< _#

Computer Nerd Kev <not@telling.you.invalid> wrote:
>
> It _sounds_ like the GPU might be better supported in Linux than
> the Raspberry Pi one. I would have liked to see it use a Pi 4
> Compute module for easier availability of future upgrades, which
> I'd prioritise above open-source personally. The module they're
> using is something of an equivalent to that though, the latest
> in a line of CPU/RAM boards made by a company that targets
> industrial applications (sorry, forgot the name, too lazy to find
> the page where they say it again).

https://boundarydevices.com/product/nitrogen8m-som/

As SOM vendors go they're a bit disappointing - they only have iMX6 and iMX8
modules in the range. Other vendors offer more of a spread - ARM, x86,
FPGA...

> Which is all fine for me actually. The price and ARM architecture
> are roadblocks though. It actually has a second 32bit ARM processor
> described in the specs as unused. I'd be interested in the idea of
> setting that up running an emulated x86 Linux system, also with
> WINE installed. Equally you could probably do that on a core of the
> main CPU, only using the "spare" CPU would be ideal because you
> wouldn't sacrifice normal performance. The emulated system would be
> slow for sure, but possibly fast enough for the few cases where it's
> required (eg. driver software, old/simple applications).

The 'spare' core is a Cortex M4F - it's a microcontroller with no MMU.
It won't run a desktop OS, and probably clocks ~200MHz.

> http://wiki.banana-pi.org/Banana_Pi_BPI-R2
> https://openwrt.org/toh/sinovoip/banana_pi_r2
>
> Schematics are available, though I'm not sure if they're riddled
> with important omissions like the RPi ones. I've talked myself out
> of buying one of those a few times now. :)

The Bananas are essentially Pi knockoffs - me-too copycats without the level
of software support from the Pi ecosystem. Last time I looked you had to
use hacked-up out-of-tree Linux kernel forks, and development was from
random people on forums.

Life in the Allwinner ecosystem has got a bit better of late, but looks like
Banana is a real hotchpotch of Allwinner, Amlogic, Realtek, Actions,
Mediatek... so not surprising they don't have a stable platform when they
change SoC vendor for every new product.

> As far as open-source computer hardware goes, I feel it's always
> some sort of compromise unless the CPU chip itself is open-source.
> It soon becomes a question of at what level you care about the
> openness of the design? CPU design? CPU microcode? SoC design? SoC
> peripheral firmware/s? Circuit board design? Software?

The usual problem is that designs advertised for their 'freedom' and
'transparency' typically aren't very good to use. Which means they're
limited to the small set of people who put those things above all else.

Theo

not@telling.you.invalid (Computer Nerd Kev) writes:

> Anssi Saari <as@sci.fi> wrote:

> For the radio, there's the OpenWiFi project. It's not cheap or
> convenient but the GitHub page suggests that it's working:
> https://github.com/open-sdr/openwifi
> https://www.rtl-sdr.com/openwifi-open-source-fpga-and-sdr-based-wifi-implementation/

Oh, I remember reading about this some time ago. Good effort.

>> I'd be interested in an open computer like this though, to be used as a
>> router. Needs more ethernet ports and a different case for that though.
>
> http://wiki.banana-pi.org/Banana_Pi_BPI-R2
> https://openwrt.org/toh/sinovoip/banana_pi_r2

I know but usually it's "our board runs XYZ Linux, here's an install
image on my personal Google Drive". In other words, hardware might be
nice but if the software options is build it yourself with their patches
or download their binaries, I'll pass. I'm sure it's a hurdle to get
support to official images but I'll have to insist. Or use a more
standardized architecture. Likely I'll be looking into an APU2 board if
and when the current chip shortage lifts and availability improves.

Also I'm not sure OpenWRT is up to providing a trustable OS. They seem a
little understaffed.

> As far as open-source computer hardware goes, I feel it's always
> some sort of compromise unless the CPU chip itself is open-source.
> It soon becomes a question of at what level you care about the
> openness of the design? CPU design? CPU microcode? SoC design? SoC
> peripheral firmware/s? Circuit board design? Software?

Yes yes, we need ASML and everyone to open source the software and
hardware in their equipment to be sure no nasty business is done when
silicon is manufactured. And of course constant auditing to prove the
hardware and software in use actually is what they claim it is.

Seems unlikely.

Anssi Saari <as@sci.fi> wrote:
> not@telling.you.invalid (Computer Nerd Kev) writes:
>
>>> I'd be interested in an open computer like this though, to be used as a
>>> router. Needs more ethernet ports and a different case for that though.
>>
>> http://wiki.banana-pi.org/Banana_Pi_BPI-R2
>> https://openwrt.org/toh/sinovoip/banana_pi_r2
>
> I know but usually it's "our board runs XYZ Linux, here's an install
> image on my personal Google Drive". In other words, hardware might be
> nice but if the software options is build it yourself with their patches
> or download their binaries, I'll pass. I'm sure it's a hurdle to get
> support to official images but I'll have to insist. Or use a more
> standardized architecture. Likely I'll be looking into an APU2 board if
> and when the current chip shortage lifts and availability improves.

I know what you mean, but the official OpenWRT image resolves that
problem in my opinion.

> Also I'm not sure OpenWRT is up to providing a trustable OS. They seem a
> little understaffed.

Well I trust it, but these things do become difficult when it comes
down to trust. Microsoft are very well staffed but I wouldn't trust
their router OS if they released one.

>> As far as open-source computer hardware goes, I feel it's always
>> some sort of compromise unless the CPU chip itself is open-source.
>> It soon becomes a question of at what level you care about the
>> openness of the design? CPU design? CPU microcode? SoC design? SoC
>> peripheral firmware/s? Circuit board design? Software?
>
> Yes yes, we need ASML and everyone to open source the software and
> hardware in their equipment to be sure no nasty business is done when
> silicon is manufactured. And of course constant auditing to prove the
> hardware and software in use actually is what they claim it is.
>
> Seems unlikely.

It's only going to happen if projects like this laptop prove
popular enough to show that there's a demand.

--
__ __
#_ < |\| |< _#

Computer Nerd Kev <not@telling.you.invalid> wrote:
> Anssi Saari <as@sci.fi> wrote:
> > I know but usually it's "our board runs XYZ Linux, here's an install
> > image on my personal Google Drive". In other words, hardware might be
> > nice but if the software options is build it yourself with their patches
> > or download their binaries, I'll pass. I'm sure it's a hurdle to get
> > support to official images but I'll have to insist. Or use a more
> > standardized architecture. Likely I'll be looking into an APU2 board if
> > and when the current chip shortage lifts and availability improves.
>
> I know what you mean, but the official OpenWRT image resolves that
> problem in my opinion.

I suppose it's as well supported by the vendor as many other products: throw
a product out the door with kernel 2.6.18 [1] and never ship any updates.
Or, worse, repurposing an ISP router where they actively try to prevent you
installing a new OS.

So if OpenWRT are happy to maintain the software I'm happy with that.
Thanks for the heads up.

[1] This current Ubiquiti product is based around a Linux image running
2.6.18, released 2006, and they have closed-source kernel modules so it
can't be upgraded:
https://www.ui.com/mfi/mpower/

>
> > Also I'm not sure OpenWRT is up to providing a trustable OS. They seem a
> > little understaffed.
>
> Well I trust it, but these things do become difficult when it comes
> down to trust. Microsoft are very well staffed but I wouldn't trust
> their router OS if they released one.

They are understaffed, in the sense of not having a big organisation behind
them, but on the other hand it's FOSS so anyone can join in. Many of the
ports are a single-person effort, but once it works presumably the CI keeps
it up to date.

Although I would worry they aren't getting the necessary support from a big
org like organised pen testing, rather than just relying on the crowd.

But then, when you come down to it, a lot of software projects are run by a
handful of people.

It would be nice if there was a Ubuntu or Redhat router distro though,
targeting the kind of hardware that runs OpenWRT. But then you'd still have
to maintain a lot of out of tree stuff for all the special hardware quirks.
Until such time as we get RPi router hardware, or you have an x86 router[2].
The OpenWRT router GUI on top of a regular x86 Linux distro would be handy.

[2] This kind of thing - I assume there are newer and better products now:
https://arstechnica.com/gadgets/2016/09/the-router-rumble-ars-diy-build-faces-better-tests-tougher-competition/

> >> openness of the design? CPU design? CPU microcode? SoC design? SoC
> >> peripheral firmware/s? Circuit board design? Software?
> >
> > Yes yes, we need ASML and everyone to open source the software and
> > hardware in their equipment to be sure no nasty business is done when
> > silicon is manufactured. And of course constant auditing to prove the
> > hardware and software in use actually is what they claim it is.
> >
> > Seems unlikely.

That doesn't really help until you can run your own fab ($xx billion)
because who can tell whether the open source manufacturing tools weren't
modified before they were run. And then maybe /you/ know your fab is
trustworthy, but if I want you to fab my chips how do I know you are
trustworthy?

At the end of the day you have to trust somebody.

Theo

Theo <theom+news@chiark.greenend.org.uk> wrote:
> Computer Nerd Kev <not@telling.you.invalid> wrote:
>> Anssi Saari <as@sci.fi> wrote:
>> > I know but usually it's "our board runs XYZ Linux, here's an install
>> > image on my personal Google Drive". In other words, hardware might be
>> > nice but if the software options is build it yourself with their patches
>> > or download their binaries, I'll pass. I'm sure it's a hurdle to get
>> > support to official images but I'll have to insist. Or use a more
>> > standardized architecture. Likely I'll be looking into an APU2 board if
>> > and when the current chip shortage lifts and availability improves.
>>
>> I know what you mean, but the official OpenWRT image resolves that
>> problem in my opinion.
>
> I suppose it's as well supported by the vendor as many other products: throw
> a product out the door with kernel 2.6.18 [1] and never ship any updates.
> Or, worse, repurposing an ISP router where they actively try to prevent you
> installing a new OS.
>
> So if OpenWRT are happy to maintain the software I'm happy with that.
> Thanks for the heads up.

Of course it's the Linux kernel devs who do most of the work
anyway, OpenWRT is just to get that software onto the hardware in
a usable form. They do have their own /etc/config configuration
system, but it just interfaces with more established software so
shouldn't be a major risk of security problems.

> It would be nice if there was a Ubuntu or Redhat router distro though,
> targeting the kind of hardware that runs OpenWRT. But then you'd still have
> to maintain a lot of out of tree stuff for all the special hardware quirks.

Actually I think OpenWRT uses the official Linux kernel, but with
_far_ more build options disabled than the likes of Ubuntu or Red
Hat (Or the vast majority of distros). That's what's needed to work
on the limited hardware while keeping the kernel up to date, but if
you tried to make a version of Ubuntu that way you'd immediately
find that a lot of software that runs in normal Ubuntu just
wouldn't work, or needs features disabled at build-time. So you'd
end up with something that wasn't actually software-compatible with
Ubuntu anyway, and I'd guess that most people wouldn't consider
that to be Ubuntu at all.

Beyond that, the architectual decisions behind Ubuntu and Red Hat
just aren't very well suited to an embedded system on a low-spec
router. Better on something like the Banana Pi boards though.

>> >> openness of the design? CPU design? CPU microcode? SoC design? SoC
>> >> peripheral firmware/s? Circuit board design? Software?
>> >
>> > Yes yes, we need ASML and everyone to open source the software and
>> > hardware in their equipment to be sure no nasty business is done when
>> > silicon is manufactured. And of course constant auditing to prove the
>> > hardware and software in use actually is what they claim it is.
>> >
>> > Seems unlikely.
>
> That doesn't really help until you can run your own fab ($xx billion)
> because who can tell whether the open source manufacturing tools weren't
> modified before they were run. And then maybe /you/ know your fab is
> trustworthy, but if I want you to fab my chips how do I know you are
> trustworthy?
>
> At the end of the day you have to trust somebody.

That's what I was thinking when I mentioned earlier running a CPU
in an FPGA. It'd be a huge performance sacrifice, though probably
fast enough for most tasks besides multimedia and browsing the web
in a mainstream web browser (it might require a hardware crypto
module to be implemented separately from the CPU). But you know
exactly what's going on inside.

Well in theory at least. Really that's a bit like security through
obscurity because if everyone did it, then FPGA manufacturers could
probably find ways to inject exploits into the specific CPU
implementations that were popular, by adding secret hardware to the
FPGA chip (I'm not sure whether this could be reliably detected by
decapping chips and studying the die).

So the information security arms race continues...

--
__ __
#_ < |\| |< _#

Computer Nerd Kev <not@telling.you.invalid> wrote:
> Actually I think OpenWRT uses the official Linux kernel, but with
> _far_ more build options disabled than the likes of Ubuntu or Red
> Hat (Or the vast majority of distros). That's what's needed to work
> on the limited hardware while keeping the kernel up to date, but if
> you tried to make a version of Ubuntu that way you'd immediately
> find that a lot of software that runs in normal Ubuntu just
> wouldn't work, or needs features disabled at build-time. So you'd
> end up with something that wasn't actually software-compatible with
> Ubuntu anyway, and I'd guess that most people wouldn't consider
> that to be Ubuntu at all.

I haven't built it for a few years, but last time I did their tree was
substantially different from mainline Linux. Obviously it's based on
mainline, but there's a ton of drivers for SoCs they support, as well as the
configuration for every individual router (which has their own parts bin of
whatever silicon was cheap the week the vendor shipped v7.2 of their
particular model). The OpenWRT folks pull down the out of tree tarballs
that vendors are obliged to publish under the GPL, integrate the drivers
into their tree, and then add the configuration for the all variations of
the vendor's platforms. They do the work of merging the vendor's patches
for some old version of Linux they ship and keeping them working with more
recent versions of Linux.

There's a lot of work in this and it's very customised. I don't know how
much is merged into mainline but I imagine a relatively small fraction.

Now that routers have started moving from MIPS to Arm, I don't know whether
this process has got a bit easier since Arm platforms support device-tree,
whereas for MIPS you had to build a kernel targeting your specific board.
Of course OpenWRT still has to support all the MIPS hardware out there, so I
don't think they can throw away their custom build system yet.

> Beyond that, the architectual decisions behind Ubuntu and Red Hat
> just aren't very well suited to an embedded system on a low-spec
> router. Better on something like the Banana Pi boards though.

That is true. Although I've run vanilla Debian on MIPS routers ~2005 and it
was fine (I did use a 2GB USB stick for storage though).

> That's what I was thinking when I mentioned earlier running a CPU
> in an FPGA. It'd be a huge performance sacrifice, though probably
> fast enough for most tasks besides multimedia and browsing the web
> in a mainstream web browser (it might require a hardware crypto
> module to be implemented separately from the CPU). But you know
> exactly what's going on inside.

You do? You have to trust the FPGA compile tools, which are very
complicated pieces of software. Maybe they haven't been modified to insert
a backdoor into your particular design, but you still have to trust they did
the right thing and there are subtle vulnerabilities you don't know about,
like you not providing sufficient timing constraints and your design failing
to work in subtle ways.

Theo

Theo <theom+news@chiark.greenend.org.uk> wrote:
> Computer Nerd Kev <not@telling.you.invalid> wrote:
>> Actually I think OpenWRT uses the official Linux kernel, but with
>> _far_ more build options disabled than the likes of Ubuntu or Red
>> Hat (Or the vast majority of distros). That's what's needed to work
>> on the limited hardware while keeping the kernel up to date, but if
>> you tried to make a version of Ubuntu that way you'd immediately
>> find that a lot of software that runs in normal Ubuntu just
>> wouldn't work, or needs features disabled at build-time. So you'd
>> end up with something that wasn't actually software-compatible with
>> Ubuntu anyway, and I'd guess that most people wouldn't consider
>> that to be Ubuntu at all.
>
> I haven't built it for a few years, but last time I did their tree was
> substantially different from mainline Linux. Obviously it's based on
> mainline, but there's a ton of drivers for SoCs they support, as well as the
> configuration for every individual router (which has their own parts bin of
> whatever silicon was cheap the week the vendor shipped v7.2 of their
> particular model). The OpenWRT folks pull down the out of tree tarballs
> that vendors are obliged to publish under the GPL, integrate the drivers
> into their tree, and then add the configuration for the all variations of
> the vendor's platforms. They do the work of merging the vendor's patches
> for some old version of Linux they ship and keeping them working with more
> recent versions of Linux.

Yes, you're quite right:
https://git.openwrt.org/?p=openwrt/openwrt.git;a=tree;f=target/linux/bcm63xx/patches-5.10;h=533d335e88ff63953a30f018ed054a90a28ee8e7;hb=HEAD

My memory's simply faulty. From making new packages to building
for a new target platform all of my attempts at doing something
interesting for OpenWRT have failed at a very early stage (I
couldn't get any signals out of the debugging headers for the
"new target platform" attempt), so I've never got very familiar
with the code behind it.

In fact it always seems to take me a few attempts just to get
firmware flashing over TFTP to work with my router when I get
around to an update.

> Now that routers have started moving from MIPS to Arm, I don't know whether
> this process has got a bit easier since Arm platforms support device-tree,
> whereas for MIPS you had to build a kernel targeting your specific board.
> Of course OpenWRT still has to support all the MIPS hardware out there, so I
> don't think they can throw away their custom build system yet.

Yeah, mine's MIPS actually.

>> Beyond that, the architectual decisions behind Ubuntu and Red Hat
>> just aren't very well suited to an embedded system on a low-spec
>> router. Better on something like the Banana Pi boards though.
>
> That is true. Although I've run vanilla Debian on MIPS routers ~2005 and it
> was fine (I did use a 2GB USB stick for storage though).

At the moment some features of the opkg package manager in OpenWRT
v19.07 don't work on my router with 32MB of RAM (not officially
supported, I know). I'm thinking that Debian probably reached that
point sooner, though I also know they weren't at it yet in 2005.

>> That's what I was thinking when I mentioned earlier running a CPU
>> in an FPGA. It'd be a huge performance sacrifice, though probably
>> fast enough for most tasks besides multimedia and browsing the web
>> in a mainstream web browser (it might require a hardware crypto
>> module to be implemented separately from the CPU). But you know
>> exactly what's going on inside.
>
> You do? You have to trust the FPGA compile tools, which are very
> complicated pieces of software. Maybe they haven't been modified to insert
> a backdoor into your particular design, but you still have to trust they did
> the right thing and there are subtle vulnerabilities you don't know about,
> like you not providing sufficient timing constraints and your design failing
> to work in subtle ways.

Yes that would be the easy way to insert a backdoor, to which the
answer would of course be open-source tools for the FPGA (and
assuming, as with so much software, that someone out there besides
the developers are checking through it). But as I say, you're still
then at the mercy of what the chip manufacturer can sneek into the
FPGA chip itself, so even as a theoretical proposition I agree that
it's not a general solution.

--
__ __
#_ < |\| |< _#

Computer Nerd Kev <not@telling.you.invalid> wrote:
> Theo <theom+news@chiark.greenend.org.uk> wrote:
>>
>> You do? You have to trust the FPGA compile tools, which are very
>> complicated pieces of software. Maybe they haven't been modified to insert
>> a backdoor into your particular design, but you still have to trust they did
>> the right thing and there are subtle vulnerabilities you don't know about,
>> like you not providing sufficient timing constraints and your design failing
>> to work in subtle ways.
>
> Yes that would be the easy way to insert a backdoor, to which the
> answer would of course be open-source tools for the FPGA (and
> assuming, as with so much software, that someone out there besides
> the developers are checking through it). But as I say, you're still
> then at the mercy of what the chip manufacturer can sneek into the
> FPGA chip itself, so even as a theoretical proposition I agree that
> it's not a general solution.

Sure enough, if you can think of it there's a GitHub project for
it:
https://github.com/litex-hub/linux-on-litex-vexriscv

"In this repository, we experiment running Linux with VexRiscv CPU,
a 32-bits Linux Capable RISC-V CPU written in Spinal HDL. A SoC
around the VexRiscv CPU is created using LiteX as the SoC builder
and LiteX's cores written in Migen Python DSL (LiteDRAM, LiteEth,
LiteSDCard). All the components used to create the SoC are
open-source and the flexibility of Spinal HDL/Migen allow targeting
easily very various FPGA devices/boards: Lattice, Altera, Xilinx,
Microsemi FPGAs with SDRAM/DDR/DDR2/DDR3/DDR4 RAMs,
RMII/MII/RGMII/1000BASE-X Ethernet PHYs. On Lattice ECP5 FPGAs, the
open source toolchain allows creating full open-source SoC with
open-source cores and toolchain!" ...

Top spec. for the FPGA boards that the fully open-source toolchain
supports is the "TrellisBoard": 75MHz clock, 32-bits 1GB DDR3 RAM.

A talk about it from 2020, which I might watch later:
https://archive.fosdem.org/2020/schedule/event/riscv_fpga/

Makes me wonder whether anyone _has_ looked into whether you can
detect potential hardware exploit-injectors in the FPGA through
practical die decapping and reverse-engineering methods. Maybe
easier if the FPGA die was open-source to begin with.

Ho hum, I'm not getting anything done this Sunday it seems, an
hour later I've found this suggestion within this
well-considered article on the overall topic:
https://www.bunniestudios.com/blog/?p=5706

"The placement of logic with an FPGA can be trivially randomized by
incorporating a random seed in the source code. This means it is
not practically useful for an adversary to backdoor a few logic
cells within an FPGA. A broadly effective silicon-level attack on
an FPGA would lead to gross size changes in the silicon die that
can be readily quantified non-destructively through X-rays. The
efficacy of this mitigation is analogous to ASLR: it's not
bulletproof, but it's cheap to execute with a significant payout in
complicating potential attacks." ...

--
__ __
#_ < |\| |< _#

Computer Nerd Kev <not@telling.you.invalid> wrote:
> Makes me wonder whether anyone _has_ looked into whether you can
> detect potential hardware exploit-injectors in the FPGA through
> practical die decapping and reverse-engineering methods. Maybe
> easier if the FPGA die was open-source to begin with.

In general terms, the problem with silicon trojans is not that there might
be a 'master key' that straightaway unlocks the lock, which is something you
could see support for if you opened the lock up, but that there might be
flaw in the construction such that the lock isn't hard to crack as its
designers might have intended.

If you can reduce the complexity form O(2^N) to O(N) then you've won,
because you don't need to brute-force crypto (for example) you just pick off
each bit of the key individually. Analogue weaknesses can be extremely
subtle - that you can't see by looking at the silicon (even with electron
microscopes and such). You just need a small amount of misbehaviour and you
have one of those vulnerabilities. The problem with a design produced by
a backend flow you don't understand is you don't know if that sort of thing
has been introduced.

> "The placement of logic with an FPGA can be trivially randomized by
> incorporating a random seed in the source code. This means it is
> not practically useful for an adversary to backdoor a few logic
> cells within an FPGA. A broadly effective silicon-level attack on
> an FPGA would lead to gross size changes in the silicon die that
> can be readily quantified non-destructively through X-rays. The
> efficacy of this mitigation is analogous to ASLR: it's not
> bulletproof, but it's cheap to execute with a significant payout in
> complicating potential attacks." ...

I would caveat that idea because it depends on the quality of the
verification performed by the FPGA tools. Supposing you produce a
different design for every user. The tools do timing verification to check
the design meets its timing specification. If you don't meeting timing you
potentially have a vulnerable system due to the subtleties I outlined above
(occasional data corruption etc). So now your security depends entirely
on the quality of the timing verifier, because nobody is doing QA on your
particular design once the tools were finished with it. Maybe your verifier
is open source, but how do you know how good its verification actually is?

Of course, here I'm talking about subtle attacks on crypto or
rowhammer-style attacks on memory, not phoning home your password to a
botnet - those are a different class that should be easier to spot.

Theo

Theo <theom+news@chiark.greenend.org.uk> wrote:
> Computer Nerd Kev <not@telling.you.invalid> wrote:
>
>> "The placement of logic with an FPGA can be trivially randomized by
>> incorporating a random seed in the source code. This means it is
>> not practically useful for an adversary to backdoor a few logic
>> cells within an FPGA. A broadly effective silicon-level attack on
>> an FPGA would lead to gross size changes in the silicon die that
>> can be readily quantified non-destructively through X-rays. The
>> efficacy of this mitigation is analogous to ASLR: it's not
>> bulletproof, but it's cheap to execute with a significant payout in
>> complicating potential attacks." ...
>
> I would caveat that idea because it depends on the quality of the
> verification performed by the FPGA tools. Supposing you produce a
> different design for every user. The tools do timing verification to check
> the design meets its timing specification. If you don't meeting timing you
> potentially have a vulnerable system due to the subtleties I outlined above
> (occasional data corruption etc). So now your security depends entirely
> on the quality of the timing verifier, because nobody is doing QA on your
> particular design once the tools were finished with it. Maybe your verifier
> is open source, but how do you know how good its verification actually is?

Though that's not much different to the problem of knowing how good
the crypto library you're using is. Or even the compiler that built
the Linux kernel you're running. If you have to really verify all
this code yourself to be sure, then I think it's impractical
regardless of whether the FPGA tools need to be checked as well.

If users can't trust any other developers to honestly write and
check the open-sourse software, then I think the idea's dead.
Modern computing is too many generations ahead of where one person
could competently verify everything for themselves.

--
__ __
#_ < |\| |< _#

Computer Nerd Kev <not@telling.you.invalid> wrote:
>
>If users can't trust any other developers to honestly write and
>check the open-sourse software, then I think the idea's dead.
>Modern computing is too many generations ahead of where one person
>could competently verify everything for themselves.

This is absolutely true, and this is why complete security today is
impossible.

The key to software security is to have as little software as possible
that has to run securely. The key to hardware security is to validate
the hardware as well as possible, which means having a deterministic
system with as little hardware as possible. These things are completely
antithetical to current practice.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."