Hands-On: MNT Reforms The Laptop
By Kerry Scharfglass, August 26, 2021
- https://hackaday.com/2021/08/26/hands-on-mnt-reforms-the-laptop/
open source hardware is getting much closer to perfectly reasonable
open source hardware is getting much closer to perfectly reasonable
But really, no mic, no bluetooth (or maybe if there's a compatible wifi+bluetooth card?) And slow.
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.
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).
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).
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?
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/
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
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?
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.
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:
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.
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.
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.
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.
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.
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.
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.
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.
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 <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.
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.
"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:
"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?
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.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 293 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 215:05:27 |
| Calls: | 6,619 |
| Calls today: | 1 |
| Files: | 12,169 |
| Messages: | 5,317,541 |