closed source?

[frostworx]

interesting device, found it via https://www.cnx-software.com/2024/07/08/20-nanokvm-is-a-tiny-low-power-risc-v-kvm-over-ip-solution/#comments

but are you really planning to keep it closed source?

[frostworx]

mount -t ext4 -o loop,offset=16777728 20240702_NanoKVM_Rev1_0_0.img /random/mountpoint

for the curious

edit:

whoops, forgot

mount -t vfat -o loop,offset=512 20240702_NanoKVM_Rev1_0_0.img /random/mountpoint

for the first partition

[frostworx]

a bit random grepping reveals that at least

https://github.com/hodgef/react-simple-keyboard is used in the firmware

server/web/assets/index-u2n1Wr7j.css: * https://github.com/hodgef/react-simple-keyboard

[frostworx]

see also https://news.ycombinator.com/item?id=40903461

[Zepan]

We are wondering wheter open or not. At the early time (3month ago), we want make it opensource, only make the hardware, and port PiKVM on it with few develop work. but we realize it is not easy to run PiKVM on it, as it not support V4L2. We send the hardware sample to some community developer who familiar with PiKVM, and they worked for 3month to port V4L2, and still working...(may finished in few month, when it finished, we will open PiKVM port) we have to develop FW ourself, it takes about 2~3month, and we see >95% commit of PiKVM is written by author, so we think it may not help much if we opensource at the first time? keep this as a bug report repo maybe better? Welcome feed back if you have better suggestion to work with community, we want a good balance with opensource and commerce.

[Zepan]

At least, we will open most interfaces/API for images,HID operations, that DIYer can customize their own functions without dig hard into complex bsp sdk.

[Zepan]

I make a vote on twitter: https://x.com/SipeedIO/status/1810508366336115192

[frostworx]

thank you for the comprehensive answer and also thanks for creating the poll. (personally I don't use x-twitter, so I won't take part)

[ThomasKaiser]

Not using X/Twitter either but wanting to emphasis on the open source aspect -> trust into the device being not equipped with a backdoor.

Folks are fine using whatever commercial iKVM solution but once it's open hardware but comes from China they start to worry. Especially residents of the Five Eyes states who are absolutely fine with their governments/agencies spying on everyone on this planet are trained to believe that everything that originates from China must be evil.

As such allowing users to build their own firmware image from sources will at least be a try to stop these 'concerns' your KVM device being backdoored by design.

[shangri26199]

+1 for opensource without X account

[Zepan]

Not using X/Twitter either but wanting to emphasis on the open source aspect -> trust into the device being not equipped with a backdoor.

Folks are fine using whatever commercial iKVM solution but once it's open hardware but comes from China they start to worry. Especially residents of the Five Eyes states who are absolutely fine with their governments/agencies spying on everyone on this planet are trained to believe that everything that originates from China must be evil.

As such allowing users to build their own firmware image from sources will at least be a try to stop these 'concerns' your KVM device being backdoored by design.

what about open backend(go), close frontend(react)?

[ThomasKaiser]

what about open backend(go), close frontend(react)?

I don't think that will stop people talking about your device being backdoored...

[seichold]

I bought a full and lite through the pre-order to check them out, but without the firmware being open source I do not think this will gain wide traction.

I really want this project to be successful as it brings a near order of magnitude cost reduction (and size!) to the ip based KVM world .

So take this as my (non X using) vote to work toward open source firmware.

[ElbPirat]

Also +1 on open source. Pre-Ordered one for personal use, but searching something similar for my workshop/lab at work, other professional devices are too expensive for my superior... Would try to order a few once released.

[mintisan]

If it's just for playing around, closed-source is fine, but if it involves projects or production data, then I wouldn't use it [I have already bought one].

[bilogic]

i need HDMI to a monitor as well, is it possible with this hardware? or splitter?

[denern]

I have the LicheeRV Nano board and am familiar with PiKVM, how can I help you to finish?

[M0NsTeRRR]

I'm waiting for the code to be open source before buying one :)

[joubin]

evil.

Not using X/Twitter either but wanting to emphasis on the open source aspect -> trust into the device being not equipped with a backdoor. Folks are fine using whatever commercial iKVM solution but once it's open hardware but comes from China they start to worry. Especially residents of the Five Eyes states who are absolutely fine with their governments/agencies spying on everyone on this planet are trained to believe that everything that originates from China must be evil. As such allowing users to build their own firmware image from sources will at least be a try to stop these 'concerns' your KVM device being backdoored by design.

what about open backend(go), close frontend(react)?

I know many downvoted this. But if you’re willing to open source the backend and sell an SDK for enterprises that want to build their own front end anyways and integrate with their own Idps. Not sure. There might be something there

[brainstorm]

Here's another strategy that can be a win-win for both Sipeed and regular consumers of your product:

Commit to releasing it as opensource as soon as you've sold, say, 3000 units (arbitrary amount to be decided by Sipeed). Motivation behind this is:

1. It "secures" a (fixed, minimum) income threshold for Sipeed.
2. It motivates those buyers to purchase your product to accelerate it being opensource faster.

As it stands right now I'm siding with @M0NsTeRRR's position: if there is no clear commitment to release it as opensource, I'm not interested since I know that sooner or later the binary will be reverse engineered and re-implemented as OSS anyway (plus all the other security and future maintenance related concerns outlined in this issue).

EDIT: Current reversing efforts uncover worrying flaws: https://lichtlos.weblog.lol/2024/08/how-to-reverse-the-sipeed-nanokvm-firmware

[timonoj]

I bought it first, assuming it was OSS from the beginning. I'm gonna wait for the OSS release. I can see them adding new features to their private fw every few days, but I'd rather very much just use OSS.

[scpcom]

I already took some look at LicheeRV-Nano-Build and this is what I found so far:

• freertos: contains pre-built cvitek audio libraries, did not take a closer look if this is required
• host-tools: pre-built compilers (no problem for me, can be replaced by distro/standard compliers)
• linux_5.10, opensbi and u-boot-2021.10: fully open source, can be built outside of LicheeRV-Nano-Build with minimal modifications
• middleware: contains pre-built libraries, I could not find the source for it
• osdrv: contains two pre-built modules (soph_vc_driver.ko and soph_jpeg.ko) but the source code was already released by cvitek/sophgo
• ramdisk: contains pre-built versions of standard packages like busybox (no problem for me, can be replaced by distro/standard versions)

The middleware should also be open-sourced (by the SoC vendor), it seems to be required for NanoKVM

PS: To get a better overview of the hardware related changes, I splitted out opensbi, u-boot and linux, re-based it to the original project git: https://github.com/scpcom/linux/tree/licheervnano-5.10.y https://github.com/scpcom/u-boot/tree/licheervnano-2021.10 https://github.com/scpcom/opensbi/tree/licheervnano-0.9 Currently the difference between LicheeRV-Nano-Build and my branches are only non-hardware-related like whitepaces and .gitignore.

[scpcom]

I almost finished my research on LicheeRV-Nano-Build and created the branches on forks of existing projects:

https://github.com/scpcom/linux/tree/licheervnano-5.10.y https://github.com/scpcom/opensbi/tree/licheervnano-0.9 https://github.com/scpcom/u-boot/tree/licheervnano-2021.10

https://github.com/scpcom/buildroot/tree/licheervnano-2023.11 https://github.com/scpcom/FreeRTOS/tree/licheervnano

https://github.com/scpcom/sophgo-fsbl/tree/licheervnano https://github.com/scpcom/sophgo-ramdisk/tree/licheervnano

https://github.com/scpcom/sophgo-build/tree/licheervnano https://github.com/scpcom/sophgo-middleware/tree/licheervnano https://github.com/scpcom/sophgo-osdrv/tree/licheervnano

Currently I am locally connecting them together as submodules, I may create and publish a top-level repo next, to make it easier.

If you look in the history you can see a replay of the commits to LicheeRV-Nano-Build splitted in to the sub projects. They are similar with one exception: The most interesting part is the 2.6G sized initial commit named "release" (bd39c05f39ab6d850d7c2c29a6b5ac617efc698a). If you look in the history of my branches the size is reduced to less than 2M. You can easily watch it on github or in an editor. It contains only the changes relevant for LicheeRV Nano now.

First I needed to find a point on the original project which is close to the current LicheeRV Nano version. Then I made a diff and searched for more parts to exclude. I put things like wireless drivers into separate commits. The goal was to get a better history and find the hardware relevant changes, the resulting code is identical.

Some notes about the content and references to the original projects:

buildroot sophgo does also have a 2023.11 branch, but it s not the same: https://github.com/sophgo/buildroot-2021.05/tree/buildroot-2023.11 It is clean 2023.11.2 plus overlay and some extra packages (downloads wifi firmware blobs and pre-built ld-musl-riscv64 libs) https://github.com/buildroot/buildroot

freertos Based on sophgo version with five extra tasks: camera, isp, vcodec, vi and vip https://github.com/sophgo/freertos (https://github.com/FreeRTOS/FreeRTOS) https://github.com/sophgo/FreeRTOS-Kernel (https://github.com/FreeRTOS/FreeRTOS-Kernel) https://github.com/FreeRTOS/Lab-Project-FreeRTOS-POSIX The binaries are just temp files from the compiler.

fsbl No modifications, just one extra directory symlink (plat/sg200x) https://github.com/sophgo/fsbl

host-tools Not part of LicheeRV-Nano-Build, just: https://github.com/sophgo/host-tools compilers and toolchain

linux_5.10 sophgo linux_5.10 is very close to the XUANTIE-RV version but they decided to start there branch with a blank 5.10.4 and mix XUANTIE-RV and there changes into one big commit https://github.com/sophgo/linux_5.10/ (https://github.com/XUANTIE-RV/linux)

opensbi Only few lines changed https://github.com/XUANTIE-RV/opensbi

oss Identical to: https://github.com/sophgo/oss Does not seem to contain sources, just older pre-compiled libs with headers and pkgconfig.

ramdisk Contains some extra static linked binaries and configuration. Two extra firmware blobs in rootfs/common_arm/usr/share/fw_vcodec, I do not know if the blobs are really relevant or just leftovers from older sdk version. https://github.com/sophgo/ramdisk

u-boot-2021.10 https://github.com/sophgo/u-boot-2021.10

The delta between LicheeRV-Nano-Build and the following repos (also some parts of the others) is a bit dirty because sipeed used some sdk with a different naming scheme for the chips. On the sophgo git versions they use "cv181x" in almost all cases for the chip used in LicheeRV Nano. On the sdk used by sipeed they reference 3 different names in the code and directory/file names: cv181x, mars and sg200x.

build https://github.com/sophgo/build middleware https://github.com/sophgo/middleware osdrv https://github.com/sophgo/osdrv

middleware Still the repo with most blobs: middleware/v2/modules/audio/lib middleware/v2/modules/isp/lib middleware/v2/3rdparty/cli

middleware/v2/sample/test_mmf (KVM Demo) Contains a pre-compiled lib named libmaix_mmf.a (only for riscv64) If you look in the history of LicheeRV-Nano-Build, you may find a file named sophgo_middleware.c which seems to be/was the source code for it (and sophgo_middleware.h is equal to maix_mmf.h).

middleware/v2/sample/test_mmf/media_server-1.0.1 Contains fragments based on: https://github.com/ireader/media-server https://github.com/ireader/avcodec https://github.com/ireader/sdk

If you add the missing parts you may be able to compile the libs found in middleware/v2/sample/test_mmf/media_server-1.0.1/libs

[brainstorm]

Good reversing writeup on:

https://lichtlos.weblog.lol/2024/08/how-to-reverse-the-sipeed-nanokvm-firmware

[scpcom]

Here is my version of the Nano-Build repo using the submodules described above: https://github.com/scpcom/LicheeSG-Nano-Build

[polyzium]

The frontend was recently open sourced, and the backend will be open sourced when the repository reaches 2k stars or the NanoKVM sells 10k units. See this tweet

[M0NsTeRRR]

The frontend was recently open sourced, and the backend will be open sourced when the repository reaches 2k stars or the NanoKVM sells 10k units. See this tweet

A good start, glad to see that !

[ckotte]

They should open source everything in the first hand and not wait for whatever. I bought one too because I'm interested, but I can understand why people not want to buy it if it's running on closed source.

[MatthewCroughan]

How am I supposed to trust a device that gives backdoor access to my hardware, without the ability to run or maintain my own operating system or software for it?

[polyzium]

How am I supposed to trust a device that gives backdoor access to my hardware, without the ability to run or maintain my own operating system or software for it?

The NanoKVM is based on the LicheeRV Nano. If you want to make your own firmware, feel free, the information is located here. That being said, I saw your tweet regarding concerns about stolen PiKVM code. The answer is no, their firmware is original and does not use PiKVM code. In fact, they even tried to port PiKVM to the NanoKVM hardware (if they are to be believed), but I assume it is either unoptimized or the hardware is a bit weak for it. I also suggest you look at this article regarding reverse engineering of the firmware and software inside. I am pretty sure that the firmware is original again, considering that most of PiKVM is written in Python+C, while Sipeed's implementation uses Golang. As for the security concerns, Sipeed has acknowledged them and will release a stable and more secure firmware in the near future. The product listing says "beta version" for a reason.

[MatthewCroughan]

@polyzium I saw those claims that they tried to port kvmd and related code, which is why I am surprised to see that they have none in their end product. Overall the release process for this thing hasn't been transparent enough for what the product does (provide backdoor access to your hardware). I'm aware of all of the things I can do myself, but I haven't got my hands on the hardware yet, despite applying for the beta boards. I was looking forward to putting NixOS and kvmd on the device, or building open firmware with Nix, for it.

[polyzium]

which is why I am surprised to see that they have none in their end product

IIRC they said it would be an option in the future. The reason it's not out yet is because it's too slow to be usable.

Overall the release process for this thing hasn't been transparent enough for what the product does (provide backdoor access to your hardware).

I'm not sure what you mean by "backdoor". Do you mean an actual backdoor set up by the manufacturer so that the Chinese can spy on you, or the very function that this device does (basically VNC, but at the hardware level)? In the case of the former, I'd advise analyzing the traffic and blocking any calling home IPs with something like a PiHole.

I was looking forward to putting NixOS and kvmd on the device, or building open firmware with Nix, for it.

What is the point? Nix is a package manager (not to mention with a STEEP learning curve) and the firmware/rootFS doesn't even have a package manager to begin with. Also, this device is many times weaker than a Raspberry Pi, and the firmware consists of a barebones Buildroot rootFS with Busybox. It's like putting Ubuntu on a microcontroller. Let the device do what it's designed to do.

[MatthewCroughan]

I'm not sure what you mean by "backdoor"

An IP KVM is a way of getting into hardware you control out-of-band. It is a backdoor into your network and your hardware. One that only you should control.

What is the point? Nix is a package manager

Nix is something that lets you create a reproducible operating system and deployments that you control, that is easy to maintain, keep up to date, rollback in the event of mistakes. Its methodology makes porting software and targeting new hardware much easier. I think the advantages of using it are obvious.

Also, this device is many times weaker than a Raspberry Pi, and the firmware consists of a barebones Buildroot rootFS with Busybox

See the following:

• https://www.liminix.org
• https://github.com/cleverca22/not-os

It's like putting Ubuntu on a microcontroller

No, it isn't.

[polyzium]

An IP KVM is a way of getting into hardware you control out-of-band. It is a backdoor into your network and your hardware. One that only you should control.

I wouldn't put it that way. I would say that an IPKVM is a hardware-level remote desktop solution, like I said, basically hardware-level VNC. Most rack-mount servers like HPE ProLiant have IPKVM built in, so following your logic, are you saying that every rack-mount server has a backdoor? That would sound VERY alarming. Sipeed is clearly marketing this device as an IPKVM that allows you to "access your computer from anywhere". So I would consider the whole "not transparent enough" argument invalid.

Nix is something that lets you create a reproducible operating system and deployments that you control, that is easy to maintain, keep up to date, rollback in the event of mistakes. Its methodology makes porting software and targeting new hardware much easier. I think the advantages of using it are obvious. See the following:

Whatever you say, this is a device you own and you are free to do whatever you want with it. I can't judge NixOS because of my limited experience with it. The only thing I can say is that I tried NixOS in a VM and 2 hours later my brain was melting; common conventions like FHS don't even literally exist in NixOS, they are thrown out the window, and that's where the steep learning curve starts. But I digress. If I wanted a reproducible system, I'd use a container or pre-built images.

[MatthewCroughan]

are you saying that every rack-mount server has a backdoor

Yes, that only the owner of that system controls. They're also called out-of-band management solutions, but I prefer to call them a backdoor, to keep myself conscious that they are a security critical piece of equipment that if mismanaged would compromise the rest of the system, since whoever has access to the backdoor has access at a lower level.

Sipeed is clearly marketing this device as an IPKVM that allows you to "access your computer from anywhere"

"Access your device from anywhere".

Using their closed source firmware, that isn't reproducible or modifiable by the consumer. I think it's understandable that I have difficulty trusting this, because you have to trust something, and this is hard to trust for me.

If I wanted a reproducible system, I'd use a container or pre-built images.

For me, it cannot be ignored that container images are more popularly used to distribute artifacts of unreproducible build processes.

A preference for pre-built images rather than sources is usually an indicator that something lacks reproducibility. Because otherwise you'd just provide sources and a reproducible build processes, which you can of course then use to create an image for use with containers.

Sometimes images are provided for convenience, or as part of a deployment that requires bit-for-bit determinism to be applied, like A/B updates to fleets of devices, and have legitimate uses. This is not what I'm referring to. Images can be outputs of reproducible build processes, but often images are provided instead of reproducible build processes.

Storing, distributing, and relying solely upon images of unreproducible build processes, rather than providing sources and reproducible build processes, means that making modifications to the original software, or even validating that the image is derived from original software sources, is more difficult, reducing the overall auditability of the software stack.

The TL;DR of that, is that just because you can tar something up and give it to me, doesn't mean I can re-apply the process that created all the things you tarred up, given only the sources. That is much harder, and is the domain of reproducible builds, and things like Nix. Calling images "reproducible" is a misnomer, I think.

Given all of the above, you can see why I might want to address that and build a reproducible operating system for this KVM, as I already have for the Pi CM4 based devices. I don't have access to the hardware, though I may have the ability to play with one soon, since someone who pre-ordered it might have it by the time we meet up for an event.

[hadleyrich]

@sipeed do you have any updates on the full source for this? It seems like you're shipping half baked products at the moment.

https://github.com/sipeed/NanoKVM/issues/1#issuecomment-2278831374

[scpcom]

are you saying that every rack-mount server has a backdoor

Yes, that only the owner of that system controls. They're also called out-of-band management solutions, but I prefer to call them a backdoor, to keep myself conscious that they are a security critical piece of equipment that if mismanaged would compromise the rest of the system, since whoever has access to the backdoor has access at a lower level.

Only the owner of that system? Does anyone have source code for Dell iDRAC or HPE iLO? Can you install your own firmware?

Sipeed is clearly marketing this device as an IPKVM that allows you to "access your computer from anywhere"

"Access your device from anywhere".

Using their closed source firmware, that isn't reproducible or modifiable by the consumer. I think it's understandable that I have difficulty trusting this, because you have to trust something, and this is hard to trust for me.

The LicheeRV Nano firmware is open and reproducable (as you can read above). And you can customize it. Currently there are only two components that are not fully open: middleware and the NanoKVM web server. And this is what we are talking about here.

[MatthewCroughan]

@scpcom

Only the owner of that system? Does anyone have source code for Dell iDRAC or HPE iLO?

Precisely. Scary, isn't it? :)

The LicheeRV Nano firmware is open and reproducable (as you can read above)

Have you got a link to a git repository containing the source code you're talking about, just so we're clear that I know what you're talking about.

WebServer and Middleware are still two pieces of closed source software that are running as root according to lichtlos' reverse engineering blog post. The webserver is a huge 13MB binary, so it could be quite literally doing anything at all, no question about that.

Would be nice to confirm they are running as root with ps aux, though I don't have a device to test anything yet.

[scpcom]

Only the owner of that system? Does anyone have source code for Dell iDRAC or HPE iLO?

Precisely. Scary, isn't it? :)

Are you joking or can you give me a link to the sources?

Have you got a link to a git repository containing the source code you're talking about, just so we're clear that I know what you're talking about.

This is the main repository: https://github.com/sipeed/LicheeRV-Nano-Build Just scroll up for full description: https://github.com/sipeed/NanoKVM/issues/1#issuecomment-2270716285

[MatthewCroughan]

Are you joking or can you give me a link to the sources?

No, I'm agreeing with you that it's scary that the sources aren't available to such critical equipment?

[scpcom]

OK, I agree this is scary. To be fair, Dell seems to release some of the sources: https://opensource.dell.com/releases/idrac9/

But the chance to build and run your own firmware is much better on NanoKVM, I hope to see the missing parts here in the next weeks :-)

[geerlingguy]

I just received a couple of these devices to review (I have been in contact with Sipeed over the past couple months)—I am very excited about the hardware, but like others in this thread share concerns over recommending it (or even running it outside a locked down vlan) because even if there are no geopolitical backdoor concerns, I like to easily see the provenance of the code I run on all my critical systems (hardware that can remotely press a power button or enter keystrokes on one of my servers is by definition critical!).

I also heard the PiKVM code may even run on this hardware, which is great, even if slower—it would at least allow an alternative if Sipeed doesn't end up open sourcing all the code.

Some people aren't as worried about open vs. closed source, but I think especially with NanoKVM being a RISC-V-adjacent project, it would be much easier to recommend with everything being as open as possible.

[polyzium]

Hi @geerlingguy! Did not expect to see you here! Love your channel!

The hardware is based on the LicheeRV Nano running on a RISC-V SoC, and there's plenty of documentation on it, so if you want to write your own firmware, you can. The fact that Sipeed wrote their own firmware from scratch does raise such concerns, but considering that it's slowly becoming open source--not to mention a PiKVM port--it gives some hope for the future of this project. Hell, the RISC-V architecture itself is open, so it would make sense that the entire ecosystem of hardware, software and firmware working in symbiosis would be open.

[scpcom]

I also heard the PiKVM code may even run on this hardware, which is great, even if slower—it would at least allow an alternative if Sipeed doesn't end up open sourcing all the code.

Some people aren't as worried about open vs. closed source, but I think especially with NanoKVM being a RISC-V-adjacent project, it would be much easier to recommend with everything being as open as possible.

I think with PiKVM or any other alternative we still need the libs to encode the video stream with hardware acceleration.

Currently I am wiping all not required closed source libs from LicheeRV-Nano-Build. I also found some additional sources for required libs that can be integrated.

But 7 closed source libs are still required (for the KVM Demo that I use to test it):

middleware/v2/modules/isp libae libaf libawb libisp_algo libjson-c (blob also found in json-c.tar.gz)

oss/oss_release_tarball libcvi_json-c (from cvi-json-c.tar.gz) libcvi_miniz (from cvi-miniz.tar.gz)

I will provide more information (and git commits) when I am done testing it on the real hardware.

[CRCinAU]

I've got a pre-order in for 5 of the full units. Would be good to see the code opened so I can build my own if/as required.