Response to concerns about NanoKVM security

[Zepan]

In apalrd's recent video (https://www.youtube.com/watch?v=plJGZQ35Q6I), apalrd raised several security concerns regarding NanoKVM.
We have carefully watched the video—some parts are fair, while others result from an incomplete understanding of the product.
To help users better understand these concerns, we are providing a unified response under this issue. We welcome objective discussions.

Security vs. Usability Trade-off

Before discussing the details, we want to clarify a fundamental fact: security and usability are inherently contradictory to some extent. If one pursues absolute security, usability will be significantly compromised. apalrd represents a group of users who prioritize security to the extreme. However, based on our customer support records, a large proportion of users care more about ease of use.

For example, we receive multiple emails daily from users who have forgotten their self-set passwords and need help recovering them. apalrd also pointed out that our page "reminds" users to change their passwords rather than "forcing" them to do so, considering this a security risk.

In fact, we did consider forcing password changes during the initial product design. However, after shipping the alpha version, we found that a significant proportion (perhaps over 50%) of our users are beginners. If we force them to change their passwords, they are likely to forget them. Additionally, those who forget their passwords typically do not read the wiki (which contains instructions for physical factory reset). This would leave them unable to use the product or require them to send support emails.

Thus, we chose to remind rather than force users to change their passwords. apalrd mentioned that many IoT devices have similar security issues, but aside from actual security risks, some design choices are compromises for usability.

Responses to Other Concerns Before Discussing Security Details

We understand apalrd’s strong focus on security. However, as a product designed for a wide range of users, we must balance security and usability. We believe different user groups have different needs, so we made trade-offs in our product design accordingly. If apalrd had carefully read the wiki before using the product, some misunderstandings in the video could have been avoided.

Responses to Non-Security Design Issues

1. Does the full version require disassembly for reflashing?

• No. We considered factory reset and reflashing methods in the design, as detailed in the wiki. By holding the BOOT button while powering on via USB, the device enters flashing mode. At this point, U-Boot enters UMS mode, allowing users to flash the image via dd or BalenaEtcher.

2. Is using Type-C for ATX power control an abuse of USB cables?

• Similar products use RJ11 for ATX power control, but this has two issues:
  1. Size: While RJ11 is acceptable for PiKVM, it is too large for NanoKVM.
  2. Availability: RJ11 cables are not always readily available at home. If users lose them, they must pay extra for replacements.
• We specifically chose the smaller Type-C interface, allowing users to use readily available A-to-C cables of flexible lengths.
• Regarding apalrd’s concern about potential damage from plugging in a normal USB cable, we considered this issue during design. Our implementation ensures that even if a standard USB signal is inserted, it will not cause electrical damage.

3. Issues with PCIe naming and installation

• The name “PCIe” was chosen based on a Twitter poll. Although it does not use PCIe communication, users still preferred this name for clarity.
• apalrd did not carefully read the wiki or fully understand the PCIe version’s design. He assumed it was only mechanically fixed and did not address wiring or electrical functions.
• The PCIe version was specifically designed for ATX case installation. While it has an external USB-C port, our recommended installation method is internal, using the provided DuPont cables to connect to the internal USB header, avoiding extra external wiring.
• The PCIe slot is not just for mechanical fixation—NanoKVM draws power from PCIe 3.3Vaux, which remains powered even when the PC is off. Thanks to NanoKVM’s ultra-low power consumption (<1W), it can run continuously from 3.3Vaux without external power.
• In fact, NanoKVM-PCIe requires only an HDMI connection to function externally, contrary to apalrd’s claim that it still needs multiple cables.
• In an earlier design, we even considered connecting the PCIe wake# signal for wake-on-LAN functionality but later removed it based on overall usage considerations.

4. Misunderstanding between system images and app versions

• In the video, apalrd mentioned that the system image was from three months ago and outdated. However, he confused the system image with the app version.
• The system image serves as a stable base. Once the fundamental drivers are in place, it does not need frequent updates.
• However, we continuously update the app, incorporating user feedback, feature enhancements, and bug fixes—even modifying original system files when necessary.

5. Misinterpretation of the open-source repository’s purpose

• apalrd assumed we rely on the community for development. In reality, most PRs are for UI language translations, with very few for core functionality (for which we offer free new products as rewards).
• We never intended for the community to take over development. Based on our experience with many prior open-source projects, commercial product development cannot rely on uncertain community contributions.
• The main reason for open-sourcing NanoKVM is transparency—to prove there are no "Chinese backdoors." As apalrd’s own analysis confirmed, there was no evidence of intentional backdoors.

Response to Security Concerns

To address the security-related concerns, I have categorized all the issues and will respond accordingly.

Design Trade-offs for Usability and Availability

1. Password Change Policy
   -As mentioned earlier, we chose to "remind" users to change their passwords rather than "force" them to do so.
2. Forced DNS Modification

• Some users in certain regions experience domain resolution failures with their local DNS providers, preventing access to Sipeed’s servers and causing update failures. To ensure availability, we enforced the use of reliable DNS services. While this decision may raise security concerns, it was made purely to guarantee usability for all users.
• The issue you mentioned—"installation failure due to network restrictions in China"—is an example of such network-related problems.
• Once again, security and usability are often in conflict, and we aim to strike a balance. Some harmless actions may cause unnecessary concerns.

3. Bundled Outdated Version of Tailscale

• During the Alpha hardware release, we did not preinstall Tailscale in the image. However, some users in certain regions were unable to access Tailscale's official website, so we used a CDN to distribute a fallback version.
• In the final official image and hardware versions, this fallback link is not needed.
• This was purely a usability-driven decision—just because your network can download Tailscale without issues, it doesn't mean all users around the world can do the same.

Non-Security Issues / Other Feature Enhancements

1. Default Installation of tcpdump and aircrack

• These packages were enabled by default in the original SDK for the SG2002 platform, and we initially retained the default configuration without much attention.
• However, these tools have proven useful for diagnosing network issues users encounter. This has been evident in comments under your video and discussions on GitHub issues.
• Additionally, our PCIe version includes WiFi support, and to avoid fragmenting the image versions, we provide a unified firmware image. As a result, some software packages may be present even if they are not immediately needed for a specific hardware variant.

2. NanoKVM Lacks MFA Support

• This is something better suited as a "TODO" item, and we will update the README roadmap accordingly.

3. Closed-Source Libraries

• This issue has already been addressed in the corresponding GitHub issue.
• NanoKVM is a side project of MaixCAM, and for rapid development, we reused some proprietary MaixCAM libraries.
• However, these libraries only handle chip-specific video encoding/decoding and do not contain anything concerning.
• In fact, community developers have already reverse-engineered and reimplemented the necessary functionality.
• In the next version, we will remove these dependencies to eliminate unnecessary speculation.

Security Concerns Stemming from Tailscale or Network Configuration

1. NanoKVM as a Router

• The Tailscale startup script sets ip forwarding = 1, effectively turning the device into a router.
• Since enabling Tailscale automatically configures this setting, we provide users with the option to enable or disable Tailscale.
• Users can also manually remove /etc/sysctl.d/99-tailscale.conf if needed.

2. NanoKVM Identified as an "InternetGatewayDevice"

• It is enabled by default in the original SDK for the SG2002, we can disable it next time

Beneficial Security Recommendations

1. Potential Issues with SSH Enabled by Default
   Initially, NanoKVM was designed as a product for homelab developers. Therefore, we set the product to "Developer Mode" by default, enabling SSH to facilitate network diagnostics and recovery for developers. Many of our previous designs and configurations, as well as our earlier products like SBCs and AI Cameras, were also tailored for developer users. However, as NanoKVM reaches more general users, it is indeed time to default to a "Regular User" mode, with "Developer Mode" requiring manual activation.

2. Hardcoded Keys in TypeScript
   Yes, this was an improper practice, a flaw left over from the early rapid development stage. We plan to move the keys into configuration files in the next version, which is expected to be released this month. This improvement will further enhance product security. However, it is worth noting that the primary security risk associated with this issue is man-in-the-middle attacks, meaning that the risk arises mainly when your network is untrusted or malicious. In such cases, the number of potentially compromised devices around you may be greater than expected.

3. Lack of APP Update Verification

Similar to the previous issue, we will add verification in the next version. The primary risk also comes from man-in-the-middle attacks.

Summary

We are always committed to finding the best balance between security and usability and appreciate the feedback from apalrd and other users.
We will continue improving NanoKVM to ensure it meets the security needs of advanced users while remaining simple and user-friendly for beginners.
We welcome all users to transparently discuss and provide suggestions in an open-source environment. Whether the concerns are genuine security issues or security concerns influenced by bias, they can be properly addressed in a transparent, open discussion.

Additionally, we recommend users read our Wiki documentation before using NanoKVM to fully understand its features and usage.

For any questions, our technical support team is always available: [email protected].

[alexhk]

When you say "next version", are you talking about a new hardware (NanoKVM Pro), or a software update for current NanoKVM users?

[mcsrobert]

This feels really dismissive. Let's take the hardcoded DNS servers as an example, but this applies to multiple issues responded to here.

Hardcoded DNS is a pretty obvious bad practice. Your reply is: "Some users in certain regions experience domain resolution failures with their local DNS providers."

Then why not have a sane default and offer those few users who need to take extra steps the ability to easily change the DNS server?

Just because users in China are behind a firewall, doesn't mean that by default this device should ignore the DNS server in my network.

[wj-xiao]

When you say "next version", are you talking about a new hardware (NanoKVM Pro), or a software update for current NanoKVM users?

The software update.

[wj-xiao]

This feels really dismissive. Let's take the hardcoded DNS servers as an example, but this applies to multiple issues responded to here.

Hardcoded DNS is a pretty obvious bad practice. Your reply is: "Some users in certain regions experience domain resolution failures with their local DNS providers."

Then why not have a sane default and offer those few users who need to take extra steps the ability to easily change the DNS server?

Just because users in China are behind a firewall, doesn't mean that by default this device should ignore the DNS server in my network.

We will remove the modification operation and no longer modify the DNS configuration file.

[sean-wilkinson]

Hardcoded Keys in TypeScript
Yes, this was an improper practice, a flaw left over from the early rapid development stage. We plan to move the keys into configuration files in the next version, which is expected to be released this month. This improvement will further enhance product security. However, it is worth noting that the primary security risk associated with this issue is man-in-the-middle attacks, meaning that the risk arises mainly when your network is untrusted or malicious. In such cases, the number of potentially compromised devices around you may be greater than expected.

Why move the keys to a config file? The problem here is the fact that the password is encrypted and can be decrypted with a key.

1. The password and salt should be hashed by the browser using a one way hash function such as sha256.
2. The hash is sent over the network
3. The Server (NanoKVM) should compare the hash with the hash stored locally.
4. If the hashes match authentication was successful.

Employing Symmetric-key cryptography such as AES256 for login functionality such as this is very suspicious as it allows a man in the middle to decrypt the password if they have the key.

Using a one way hash function does not allow a threat actor to recover the password unless they have a very VERY large GPU farm to crack the hash.

These are basic security fundamentals.

[PatrickHuetter]

Dear Sipeed Team,

I assume that due to the recently released video, you will now receive increased feedback as well as critical messages—some of which are justified. However, I am convinced that you can use this situation as a great opportunity to become even more successful in the long term.

My advice: Support the open source community by releasing all the information needed to build a clean and efficient open source firmware. You will see that many more people will be willing to purchase your hardware because that is your unique selling point!

Personally, I would have bought the nanoKVMs much earlier if the open source aspect had been clearly resolved and everything had been made open source. Don’t be afraid to build something great together with the community—and don’t fear competition. If you deliver top-notch hardware while quickly and sustainably fixing the software issues, your project will be celebrated and widely adopted.

I truly appreciate the price/performance ratio of your hardware—even compared to the JetKVM. Now it’s up to you to optimize the software and release it fully open source. Be smart and let the community help you.

Best regards!

[ddscentral]

I personally find apalrd’s security concerns to be perfectly valid, given what type of device this is. This is a KVM device which is used to REMOTELY CONTROL a computer.
In my opinion, security and transparency should be your top priorities, even if they can sometimes come at a cost of ease of use. This device is not a toy to play with. Well, unless you want to treat is as such.

I have acquired several NanoKVM devices but so far I only put one of them in service for testing/tinkering purposes.
I have serious doubts about putting others into service with the software in it's current state. Even though I do like the hardware.

[gshpychka]

Why don't you respond to the specific issues in this repo, some of which are about the concerns you're addressing?
Opening a tracking issue is okay, but you should respond to the issues as they're opened, not wait for a youtube video to address them in a new and separate issue.

#245
#250
#289
#192
#248
#295
#197
#294

[apalrd]

I didn't pull my comments out of thin air. I read all of the Github issues that have been accumulating here for months before making the video, and covered the ones I thought were the most significant.

The lack of action on these issues (here, on Github) speaks volumes to your commitments to security in the product.

[TheSp1der]

Honestly, I don't think the review by apalrd's video was fair. I knew going in that this device was from a possible suspect source, in reality or not, but let's be clear everything on my network is a suspect. So, I treat it that way. Using sensationalized words and phrases like "Backdoor" and "Victim's computer" seems a bit unfair when there was no evidence to indicate any of that was true.

I was suspect of these and isolated them, but, honestly, Google devices make more scary calls than this thing does.

I'll touch on a few issues here with my two cents, but I feel like @Zepan 's comments were rather sufficient.

• First, hard-coding dns servers IS bad practice, but its hardly out of the norm these days. Companies fed up with project's like Pi-Hole are starting to use this more and more frequently. I have even seen some dns-over-tls and https requests happen without my consent (from other devices, looking at you, Google.). So, I don't feel that call out is exactly fair.
• The root password, ok, so it's root? I didn't buy this thing to manage a server running in production in some fortune 500 company. I also expect to be able to manage it, which I can. I'm more concerned over the weak ssh ciphersuites this thing supports, but it's not a powerful (or expensive) device.
• Lack of TLS. Yep it lacks TLS, but you can enable that. The documentation even has instructions for you, but it does impact performance. Again, it's not a powerful (or expensive) device.
• I agree the update method requires a bit of a re-think. I would like to see the sources open as well and signed at a minimum.
• Tailscale, is installed and the daemon is running and checking in with the tailscale network. Yep, that's how that works! The odd thing here, it's not happening on my 5 devices. I suspect that is because I received my device very early, before the tailscale support was added. I have not seen this connectivity, but I also either disabled talescale or it was never enabled in the updates I have received. Tailescale is awesome and I would naturally be suspicious, but it does a lot on it's own to work, and this might not be the NanoKVM doing scary things, but tailscale. I have not seen any evidence that a tailescale network was added without my knowledge. I would rather see this disabled by default, as is my experience, but that seems to have changed during recent revisions.

In summary, yes, there are some security issues, outdated packages, weak ssh ciphers/hmac, poor update mechanism/validation to name a few. But it's a $20.00 KVM. I didn't expect the gold standard here, I trust it about as much any device, but I have seen little evidence that this is a "backdoor".

I want to say something about the timing of the release of a competing kvm product, but I have no evidence to even make an assumption. What I do want to see happen is Sipeed make good on their answers here and opensource the rest of the project, but I don't expect perpetual updates for a $20.00 KVM.

[That-Dude]

This is a KVM that is going to be connected to servers that are logged into admin / root sessions. There is no trade off with usability versus security, its 100% security first, usability second.

All of @apalrd points are valid. Your hardcoded keys, password management, unverified downloads from remote servers, dns bypassing and tailscale on by default are a security disaster waiting to happen.

Fix these issues and become the homelabbers product of choice, you'll quickly gain trust and can break into the massive SME market. If you don't do it a competitor will and you're going to miss out on a huge opportunity! I have 4 nanokvms and i think the hardware is great, but they live in a restricted vlan for the reasons listed above.

[rosshiga]

I agree it's alot of criticism for a hobby level just out of beta product but the attitude that it's just going to be used in home lab is why crap IoT security exist. This is a remote access device. Secured by design is a philosophy and unless you change your mindset the product will never be secure enough for a RAT.

The glaring difference here between you and JetKVM is that when stuff like this comes up JetKVM Team says "no, user, you will hurt yourself" in the long term if you don't change your password. You should not be making the product more insecure. Convenience is at the expense of security and it's clear what you folks believe is more important.

[swaits]

There is no reason (maybe other than ntp) a KVMoverIP device needs to reach out to the public Internet, ever. No good reason. At least not by default.

Any claim otherwise is in very bad faith.

Now, I'm going to assume you're not doing anything malicious. But, it doesn't change the need to come completely clean and fix it. Why? Hanlon's Razor:

Never attribute to malice that which is adequately explained by stupidity.

[bddanford]

Could we get the most current release of the firmware posted maybe? Some of the glaring issues can be quickly resolved. I would really like to see these devices work and have some reasonable expectation of a somewhat secured by default. If this stuff was mostly done to make PoC/testing easier, then thats fine, tell us, be up front, tell us what and why its doing it, and keep it a beta product until you are ready to lock it down more and move to more of a release candidate testing phase.

[jduncanator]

Hardcoded Keys in TypeScript
Yes, this was an improper practice, a flaw left over from the early rapid development stage. We plan to move the keys into configuration files in the next version, which is expected to be released this month. This improvement will further enhance product security. However, it is worth noting that the primary security risk associated with this issue is man-in-the-middle attacks, meaning that the risk arises mainly when your network is untrusted or malicious. In such cases, the number of potentially compromised devices around you may be greater than expected.

Why move the keys to a config file? The problem here is the fact that the password is encrypted and can be decrypted with a key.

1. The password and salt should be hashed by the browser using a one way hash function such as sha256.
2. The hash is sent over the network
3. The Server (NanoKVM) should compare the hash with the hash stored locally.
4. If the hashes match authentication was successful.

Employing Symmetric-key cryptography such as AES256 for login functionality such as this is very suspicious as it allows a man in the middle to decrypt the password if they have the key.

Using a one way hash function does not allow a threat actor to recover the password unless they have a very VERY large GPU farm to crack the hash.

These are basic security fundamentals.

While I understand the sentiment of what you were going for in this reply (and I agree, a better authentication solution is needed), implementing it exactly as outlined here also has a significant security issue.

You should never hash a password client-side, and then have the server compare that hash against the stored hash to perform authentication. Should the database ever be compromised, and the hashes of passwords leaked, it is trivial for an attacker to simply "replay" your hashed password from the database against the server and authenticate as you. You should always hash the provided authentication string (ie. users password) on the server, and then compare that against the hash in the database. Hashing the password client side, and then sending that over the network, has zero security benefits compared to just sending the password in the first place, and contributes to a false sense of increased security when in fact you've introduced a serious vulnerability.

[TuningYourCode]

I do not have a NanoKVM (yet?) but i downloaded the latest release and you can simply extract and then mount the image by sudo mount -o loop,offset=16777728,rw 20241120_NanoKVM_Rev1_3_0.img /mnt (well you need a linux system/vm) and you can edit files (e.g. remove the adding of dns servers or deletion of tailscale) and then just flash/write the modified image to your sd card.

Also there is quiet much dev stuff on the image like jquery in uncompressed and minified version, quiet many development libs etc. so if somebody wants to slim down there is quiet much potential :)

Keep in mind that even professional KVM solutions should not be connected to the internet (at least not exposed to it) i would also recommend for these devices. Even if there are no security holes this device might easily be DDoSed with it's limited resources.

I think the product is super nice for home labbers and there will be some kind of community which will provide improved images.
The only issue might be if the linux kernel etc. has parts which are not open sourced - i didn't check that but it looks promising that they already open sourced parts of their code which always helps :)

I will most likely order one to get my hands on image creation for this device.

PS: How to get to 16777728

sudo apt install fdisk xz-utils
unxz 20241120_NanoKVM_Rev1_3_0.img.xz
sudo fdisk -l 20241120_NanoKVM_Rev1_3_0.img

Now simply multiply the Start of the Linux Partition (32769) with Sektor size (512).

[sean-wilkinson]

Hardcoded Keys in TypeScript
Yes, this was an improper practice, a flaw left over from the early rapid development stage. We plan to move the keys into configuration files in the next version, which is expected to be released this month. This improvement will further enhance product security. However, it is worth noting that the primary security risk associated with this issue is man-in-the-middle attacks, meaning that the risk arises mainly when your network is untrusted or malicious. In such cases, the number of potentially compromised devices around you may be greater than expected.

Why move the keys to a config file? The problem here is the fact that the password is encrypted and can be decrypted with a key.

1. The password and salt should be hashed by the browser using a one way hash function such as sha256.
2. The hash is sent over the network
3. The Server (NanoKVM) should compare the hash with the hash stored locally.
4. If the hashes match authentication was successful.

Employing Symmetric-key cryptography such as AES256 for login functionality such as this is very suspicious as it allows a man in the middle to decrypt the password if they have the key.
Using a one way hash function does not allow a threat actor to recover the password unless they have a very VERY large GPU farm to crack the hash.
These are basic security fundamentals.

While I understand the sentiment of what you were going for in this reply (and I agree, a better authentication solution is needed), implementing it exactly as outlined here also has a significant security issue.

You should never hash a password client-side, and then have the server compare that hash against the stored hash to perform authentication. Should the database ever be compromised, and the hashes of passwords leaked, it is trivial for an attacker to simply "replay" your hashed password from the database against the server and authenticate as you. You should always hash the provided authentication string (ie. users password) on the server, and then compare that against the hash in the database. Hashing the password client side, and then sending that over the network, has zero security benefits compared to just sending the password in the first place, and contributes to a false sense of increased security when in fact you've introduced a serious vulnerability.

Yes I agree, the hash can be replayed but at least the original password can not be recovered which could potentially match the root/admin password of the host machine, as the OP stated and we all know users are bad with passwords.

This is why public-key cryptography exists, why TLS is important and should be on my default. I do understand there are performance implications in doing this thought.

As others have also stated security should be a top priority on a device such as this, the community and myself as a customer are not going to take the product seriously unless the software can be trusted and is secure.

[Zepan]

Dear Sipeed Team,

I assume that due to the recently released video, you will now receive increased feedback as well as critical messages—some of which are justified. However, I am convinced that you can use this situation as a great opportunity to become even more successful in the long term.

My advice: Support the open source community by releasing all the information needed to build a clean and efficient open source firmware. You will see that many more people will be willing to purchase your hardware because that is your unique selling point!

Personally, I would have bought the nanoKVMs much earlier if the open source aspect had been clearly resolved and everything had been made open source. Don’t be afraid to build something great together with the community—and don’t fear competition. If you deliver top-notch hardware while quickly and sustainably fixing the software issues, your project will be celebrated and widely adopted.

I truly appreciate the price/performance ratio of your hardware—even compared to the JetKVM. Now it’s up to you to optimize the software and release it fully open source. Be smart and let the community help you.

Best regards!

Yes, we have update roadmap in readme, the buildable SDK will totally availlable in Q1, before new NanoKVM-Pro release.

[wj-xiao]

In the past few months, we have been focusing on product features and user experience, and have ignored the security issues.

We simply assumed that users could rely on Tailscale to mitigate security risks when exposing their devices to the public internet. This was a mistake.

We will fix these security vulnerabilities, and a new version will be released this month.

[swaits]

It's GPL. Someone should just fork this and create a community version. I don't have the bandwidth at the moment. But might in a few months.

[jduncanator]

It's GPL. Someone should just fork this and create a community version. I don't have the bandwidth at the moment. But might in a few months.

Nearly all of the stated security issues are in the firmware/OS image, and not the user space application that is open-source.

From my understanding, the OS build sources/process and kernel tree are not open-source, and so it's impossible to build a new firmware image from scratch even if you wanted to at the moment.

I agree though, Sipeed should prioritise open-sourcing the distribution and firmware source so contributors can help fix some of these issues.

[markuman]

We will remove the modification operation and no longer modify the DNS configuration file.

For the record. The nanokvm does, once it's booted, just a few dns requests for some ntp.org domains. That's it. No more dns queries in the last 24h here (recorded with adguard home).
When it searches for updates, it asks for a google domain, a cloudflare domain and a sipeed domain.
So claiming that the devices is spyware is currently conspiracy theory.
And that the devices is calling home (which is obversley china, for a chinese company) to ask for updates, is also not a surprise.

But don't get me wrong. I don't trust China any more than I trust the US or any other government or "cloud" company.

Yes, there are some security concerns or something that is personal annoying (tailscaled when you don't use tailscale). I removed it initially after it arrives here in early december and the system load goes below 4 from 6. That alone is a reason for me to remove it.

But in the current point of time, it feels like the entire internet is overreacting.
And when someone exposes any device (without reviewing or firewalling) plain to the internet, it's not the fault of the vendor.

update 12h ago from initial comment

For the record. The nanokvm does, once it's booted, just a few dns requests for some ntp.org domains. That's it. No more dns queries in the last 24h here (recorded with adguard home).

This is only true if tailscaled is stopped and disabled.

[Freekers]

We will remove the modification operation and no longer modify the DNS configuration file.

For the record. The nanokvm does, once it's booted, just a few dns requests for some ntp.org domains. That's it. No more dns queries in the last 24h here (recorded with adguard home).

Unless you are redirecting all DNS queries on port 53 to your AdGuard instance using a firewall rule in your router, you won’t see them. This is because, as mentioned before, NanoKVM continuously changes or adjusts its DNS servers to Google DNS. NanoKVM ignores any DNS servers set via DHCP after the initial boot.

[markuman]

We will remove the modification operation and no longer modify the DNS configuration file.

For the record. The nanokvm does, once it's booted, just a few dns requests for some ntp.org domains. That's it. No more dns queries in the last 24h here (recorded with adguard home).

Unless you are redirecting all DNS queries on port 53 to your AdGuard instance using a firewall rule in your router, you won’t see them. This is because, as mentioned before, NanoKVM continuously changes or adjusts its DNS servers to Google DNS. NanoKVM ignores any DNS servers set via DHCP after the initial boot.

Yes of course I've read, watch, and noticed this all - which does not mean that is not unfixable.
And I've fixed that on my own permanently. See https://github.com/markuman/nanokvm-mitigations/blob/latest/cleanup.yml#L24-L31 with using dns: 192.168.178.50, which is my adguard home dns server - that is also distributed via dhcp in my network.

So my /etc/resolv.conf is immutable and I see all dns queries that the nanokvm is doing.

[apalrd]

A packet capture from boot also shows log.tailscale.io, stun.l.google.com, and turn.cloudflare.com, a NAT-PMP port map request, and HTTPS and STUN traffic, even when it has never been configured to do any sort of cloud connectivity. So it's not just pool.ntp.org. Obviously we know all of this is Tailscale, but an out of the box unconfigured device trying to poke holes in the firewall is absolutely not okay.

As to calling home, going to a CDN to download an update is normal, yes, but calling to a server with your serial number to get a customized binary which can't be verified to be correct is another thing entirely. Since the binaries are customized, you have no way of verifying that your binary doesn't have something malicious in it, since you can't verify the hash of the download matches what everyone else is getting. Even though nobody suspects Sipeed is doing that, the process is designed so badly that it's a clear possibility.

[markuman]

So it's not just pool.ntp.org.

Yes, if you keep it configured with tailscaled, than its more than the ntp.org request. True.
And the stun requests to google and cloudflare is also triggered by the request for updates, even if tailscaled is turned of.

Since the binaries are customized, you have no way of verifying that your binary doesn't have something malicious, ...

That's the nature of proparitary/closed software/firmware - like you get with your iPhone/Android, Fritzbox Router, Windows Notebook, Unifi Router ...

... since you can't verify the hash of the download matches what everyone else is getting.

To be honest, a hash would just safe you for a corrupt download file. 😀
To make it safe, sipeed must use dnssec, that nanokvm must validate and the firmware must be signed with gpg.

[BlwAvg]

ab3d980#diff-b335630551682c19a781afebcf4d07bf978fb1f8ac04c6bf87428ed5106870f5

They have made a roadmap with upcoming changes

[apalrd]

That's the nature of proparitary/closed software/firmware - like you get with your iPhone/Android, Fritzbox Router, Windows Notebook, Unifi Router ...

Except you can normally compare your closed-source binary files to everyone else's to see if yours has been tampered with. Just because it's closed-source doesn't mean it can't be signed and the binary hashes can't be listed publicly.

[byrevx]

/kvmapp/system/init.d/S30eth

nameserver $gw
nameserver 8.8.8.8
nameserver 114.114.114.114

Regarding these servers, yes, I think the two (Secondary or Tertiary DNS) should not exist. Any network must have a DNS, otherwise what's the point of the network to access anything through named domains? Most of us have DNS provided via DHCP, we don't bother with it too much.

The first is from Google. The second is a Chinese public DNS and is widely used in China and offers an alternative to local ISP-provided DNS services.
It was correct that the products intended for the Chinese market should have Chinese DNS and the rest with Secondary or Tertiary DNS from Google 4.4.4.4 or 8.8.8.8 and Cloudflare: 1.1.1.2 or 1.0.0.3 with malware blocking.

From what I have observed, the configuration is saved in /etc/resolve.conf , so it can practically be changed at any time, it is not written in a PROM.
Apparently there have probably been other changes, this is the first time I've looked through the code out of curiosity.

$gw is basically the network gateway that is provided or calculated. From what I can see it is initially read from /boot/eth.nodhcp and the file suggests that DHCP is not used ... then where did the gateway come from, strange.

I was going to buy myself two PCIe models, so I still don't have something to experiment with, to figure out how much "open source" or "proprietary" it is!

And as someone else said in the comments: Dear Sipeed, "don't miss this train", this year some models based on this project will definitely start appearing and if they are made "flawlessly" you have already lost a very, very big opportunity, I have the impression that you don't even realize the magnitude of it!

P.S. Maybe I got involved without being asked, and I didn't understand the code on github well at first glance!

[marcusweinhold]

And 99% wouldn't care because the nanokvm will be in a local network behind a firewall anyway. NanoKVM is for the cheaps that don't want to spend twice the price in pikvm or asus kvm card.

All the concerns of the pedantics are present in all integrated KVMs in the market. Also, from experience, I'm certain 99% of the kvms in datacenters still have the default login and password.

As an owner of NanoKVM as well as Asrock's PAUL card and multiple motherboards with builtin IPMIs, I would like to note that I trust NONE of these devices.

An example (upon many): with PAUL and the built-in IPMI on Asrock's X570 Board, you cannot set a password with more than 20 Chars. Anything longer will silently get cut off. I dare you to contact Asrock in an open forum like this to ask them to fix this issue.

Let's all appreciate, we are able to have this discussion at all. Ever tried that with Asus/Asrock/Supermicro/Dell/HP/whatnot?

[ddscentral]

True, in it's current state, NanoKVM is a pure beginner / low-skill user device not meant for more serious uses. But with the security issues fixed, it has promise to become something more.
But still, even in it's current state it's a decent device hardware-wise if you consider it's price. Also, the fact the vendor is actually responding to issues raised by customers (unlike big-name companies which often tend to ignore them unless a serious incident happens) is an achievement on it's own.

[alexisfrjp]

True, in it's current state, NanoKVM is a pure beginner / low-skill user device not meant for more serious uses. But with the security issues fixed, it has promise to become something more. But still, even in it's current state it's a decent device hardware-wise if you consider it's price. Also, the fact the vendor is actually responding to issues raised by customers (unlike big-name companies which often tend to ignore them unless a serious incident happens) is an achievement on it's own.

Better than that, you're free to change whatever you want since everything is open-source
All the other IPMIs, good luck asking and good luck changing whatever tiny thing you might not like.
As any open-source projects, stop complaining and start implementing your own, forking if necessary.

I'm pretty happy nanokvm exist for such a low budget, and for more serious uses too. All my desktops can have it and I'm free to use the security I want to. As long as there is no hidden backdoors.
In the end, like any computer, it'll be as safe as what you want it to be.

[ddscentral]

Open source stuff is indeed wonderful. If something doesn't suit your needs, change it. And that's what I do. For example, I do not like Tailscale, so I added OpenVPN and SoftEther to my NanoKVM test unit. And connected my NanoKVM to a private VPN hub in the cloud, again running open source software (again SoftEther in my case).
Tinkering with open source is also a great opportunity to gain more experience and learn how things work.

Er, went a bit off topic with this one.

[mvasl]

I ordered a full nanokvm package prior to looking deep into the project, then i looked it up, watched apalrd's review, looked at the repo with backend sources. I will probably cancel my order once it is released by customs so it can go back to china as I do not agree with how some of the points are covered here.

First of all, the bold claim that "The system image serves as a stable base. Once the fundamental drivers are in place, it does not need frequent updates." - in fact, it does.

CVE databases are populated with new vulnerabilities a multiple times a day, CVE's are opened for all kinds of components starting from the hardware and kernel and all the way up into the userspace software. Linux kernel gets patched all the time to fix identified vulerabilities and so you have to update frequently to keep up with the fixes and usually a distro maintainers handle that updates for you with unattended-upgrades or just by pushing the updated packages into the repos. The fact that, afaik, this device runs a variation of debian linux as its base system makes the attack surface quite large as there is a lot of components that are not required for this device to operate but they are still included. ALSA and the drivers for a built-in microphone are one such example, I expect there is more to be found.

Then, there is another bold claim that declines that "our page "reminds" users to change their passwords rather than "forcing" them to do so" is a problem.

Well, it also is - using devices with default and publicly known authentication data from the factory is effectively equivalent to using the devices without ANY authentication at all. This is certanly not something you expect or want from a device capable of remote control of your hardware and reaching into your internal networks. Especially when it targets people with little to 0 technical skills, as they will not be able to properly secure it by themselves.

There are lots of other things I would like to point out but this is already a pretty big wall of text and I have no intent to turn this into a full-size blog post (and I'm also pretty lazy and don't want dedicate any more of my time to do so)

[glitchsys]

Ok. Did anybody notice that this device works completely offline? That it gets a private IP and if you connect to it with your browser, you can control the device it's connected to? If you're that concerned about security, just have your router/firewall disable all internet access from this device. Done, problem solved, move on. The device works 100% offline, so if if you want maximum security, keep it offline. Then use something like a vpn into your home network in order to access the device via its private IP. That's what I'm going to do with the 3 I just ordered. My firewalla will block its internet access, and I'll just wireguard into my home network if I need to kvm into my servers.

And for those concerned about this device being "hacked" and it being connected to "important" servers, please tell me you don't leave these servers logged in as root or some administrator account. Please tell me you also practice good local physical security by locking your screen or logging out when you're not in front of the server. And that you also have things like complex passwords and maybe MFA or tight policies about multiple failures.

Could this thing have improved security? Absolutely. Is the developers showing a willingness to do so? Yes. Will they get it absolutely perfect to make all of you happy? Nope. I think tightening the security as much as REASONABLY possible without compromising too much development time is a good idea. Letting the community help you and maybe submit PR's to improve security is also a good idea. But by all means don't bend over backwards to every users demands. Maybe even add a "offline mode" button / check-mark / option a user can easily enable that will disable all external communication of this device, make it work purely internally. That would help with a lot of security-conscious that don't want to bother having their firewall block the device. Also put up some notices/warnings that a user should always ensure the computer they're connecting this device to is not left logged in. Similar to the notice that they should change the default password. You know, common sense stuff.

[alexisfrjp]

First of all, the bold claim that "The system image serves as a stable base. Once the fundamental drivers are in place, it does not need frequent updates." - in fact, it does.

How often updates of your devices are available? Even my galaxy s24, which is more critical than nanokvm, hasn't received an update from samsung in months.

Do hou even know what gets updated in the linux kernel? 99% are irrelevant to what nanokvm uses. Why would you get security updates for wifi cards or graphics cards when nanokvm doesnt even have them.

Just ridiculous comment

[mvasl]

How often updates of your devices are available?

My phone gets security patches every month as it should. All of my macbooks get security patches from apple around once per 1-1.5 month. Both of the servers i run on debian linux have unattended-upgrades, i dont know exactly how often, but pretty sure more than once per month.

Do you even know what gets updated in the linux kernel?

I work for a vendor of a k8s distribution that comes with a ton of third party packages that we build from source, patch and integrate, going as low-level as ebpf probes in the kernel. We are legally obligated to provide all source code for govt certifications and we also obligated to patch any CVE's known at the time of certification, so to answer your question - yes, I know.

[protonchang]

If you're that concerned about security, just have your router/firewall disable all internet access from this device. Done, problem solved, move on.

Well, this is basically what I did with my own NanoKVM, using a separate VLAN and no Internet access.
To me, it's a bad idea to let any kind of KVM device have a direct Internet connection, including the fancy Aspeed IPMI that comes with enterprise hardware.
However, that is no excuse for Sipeed not fixing the security vulnerabilities associated with this device.
Security improvements are always good, but until those improvements are implemented, there are still many methods available to mitigate the problem.

[wj-xiao]

Image version v1.4.0 and Application version 2.2.0 have been released, addressing most known security vulnerabilities.

Please refer to the Flashing documentation for instructions on how to update.

We are actively working to address remaining issuess. Please report any new security concerns or issues to help us further enhance the system.

[Welved]

Uh... yea, I noticed this myself a week ago. I had no idea this was a known issue. This device calling out to random (while completely legit) is very concerning.

Anyone know how to wipe and install a more legitimate IPKVM distro?

[gshpychka]

Uh... yea, I noticed this myself a week ago. I had no idea this was a known issue. This device calling out to random (while completely legit) is very concerning.

Anyone know how to wipe and install a more legitimate IPKVM distro?

What are you referring to?

[n3gwg]

Image version v1.4.0 and Application version 2.2.0 have been released, addressing most known security vulnerabilities.

That sounds great, however, I think most people will wait until @apalrd updates his review. A lot of folks trust him. Perhaps it would prudent for you to reach out to him to re-evaluate your failed product with the new code you have written. He is a very fair minded person, I am sure he will speak positively of your product succeeding an evaluation demonstrative of an improved security posture addressing all his concerns.

Yet, it is absolutely shocking that your company thought these security problems were "okay" to impose on unknowing users. That is abhorrent and reprehensible.

[Korenchkin]

I personally find apalrd’s security concerns to be perfectly valid, given what type of device this is. This is a KVM device which is used to REMOTELY CONTROL a computer. In my opinion, security and transparency should be your top priorities, even if they can sometimes come at a cost of ease of use. This device is not a toy to play with. Well, unless you want to treat is as such.

I have acquired several NanoKVM devices but so far I only put one of them in service for testing/tinkering purposes. I have serious doubts about putting others into service with the software in it's current state. Even though I do like the hardware.

this is why you should ALWAYS use separate network for management,and then i don't understand your concern...even tiny mikrotik can do everything you need and the device will never see internet
edit: this is true for any kvm - onboard/separate...
and also,i see people already doing this,so..yeah

[n3gwg]

I personally find apalrd’s security concerns to be perfectly valid, given what type of device this is. This is a KVM device which is used to REMOTELY CONTROL a computer. In my opinion, security and transparency should be your top priorities, even if they can sometimes come at a cost of ease of use. This device is not a toy to play with. Well, unless you want to treat is as such.
I have acquired several NanoKVM devices but so far I only put one of them in service for testing/tinkering purposes. I have serious doubts about putting others into service with the software in it's current state. Even though I do like the hardware.

this is why you should ALWAYS use separate network for management,and then i don't understand your concern...even tiny mikrotik can do everything you need and the device will never see internet

NanoKVM by and through its representative Korenchkin,

Well you know, companies that care about security of their networking products do not tell people that it's okay for their products to have security holes when the real responsibility is for the customer to configure their network so that a lack of care in remediating security holes can remain persistent. That is a bunch of nonsense and as a representative of NanoKVM, you should be ashamed of yourself. Not that I disagree that a separate management network (VLAN) is not a good idea, I do the same, but I still feel it is outwardly irresponsible for any company or its duly appointed representative (you as far as I can tell) to justify this lack of care and rampant irresponsibility.

Moreover, it is my personal opinion that if it were my company selling this product I'd be worried about the potential for legal liability if my product caused someone's network to be hacked into. Any time a manufacturer realizes that it's product has flaws (security flaws in the instant case) and then purposefully refuses to remediate them it opens itself to product liability claims. All one has to do is remember the Ford Pinto. Granted, no one is dying here, but the point is the same. Companies can easily get sued under product liability laws. It is an arrogant and stupid posture for you to argue that your company is justified in such a manner.

Good luck and I hope your company takes a greater level of responsibility in perfecting a correction to the issues as outlined by @apalrd herein above.

[glitchsys]

Wow, you guys are all way too harsh. This is not some multi-million dollar corporation selling some premium-priced product. This is ultra-cheap KVM device from a small time company and they're doing the absolute best they can and you're all roasting them like you expect the world from this cheap device. Amazing... I guess it's true that you just can't please everyone. I for one am very grateful they released a cheap KVM, I needed a cheap solution to control my home server the few times it gets stuck during a reboot.

THANK YOU NanoKVM for all that you've done and the cheap price point and for at least acknowledging the potential security issues and attempting to address them, I'm most grateful for all that you've done. Please keep up the good work, keep releasing updates and new hardware and ignore these naysayers, somebody is always going to complain and have issues, it's the nature of the internet. But I'm a happy and grateful user, the price point is amazing, and the fact that you even respond to us and are attempting to address these concerns is amazing (good luck trying to get a big faceless corporation to do that sometimes without going through multiple tickets and escalations and whatnot).

Personally I'll just have my firewall block internet access to the device, at least for now, because I LOVE that it works completely offline / locally. I have no problem VPN'ing into my home network and then accessing this device for the few occasions I need to KVM into one of my servers or gaming PC or something. IF I were to make a feature request, it might be some kind of "offline only mode" option that would instantly make the NanoKVM cease all external communications. This would help appease those security nuts if they're really so worried about this thing reaching out to the internet.

[Korenchkin]

@n3gwg i see it as cheap kvm with great features,for the price,how is this different from any "security" camera? it is somewhat hackable(as opposed to security cameras),so,pushing nanokvm devs to do something usable is okay,but taking it as a security threat? really? also i'm not a nanokvm representative...
and,i have a tip for a network pros - static ip and no gateway and you don't need firewall...or route its ip to loopback interface on router...

[glitchsys]

@n3gwg i see it as cheap kvm with great features,for the price,how is this different from any "security" camera? it is somewhat hackable(as opposed to security cameras),so,pushing nanokvm devs to do something usable is okay,but taking it as a security threat? really? also i'm not a nanokvm representative... and,i have a tip for a network pros - static ip and no gateway and you don't need firewall...or route its ip to loopback interface on router...

Exactly, 100%. But a cheap security camera company may not be as responsive to its user base, may not try to fix their security issues unless they had no choice. I'm grateful that nanokvm at least is aware of the issues, acknowledges them, and is making attempts to address them. That's a lot more than a lot of companies out there do and they should at least get some appreciation for that. If the "network pros" out there are truly concerned, and they don't know how to stop a device from accessing the internet..., let them go and buy an "enterprise grade" IP KVM from HPE, Raritan or ATEN for $600+

[n3gwg]

Deon, et alia:

Firstly, we are discussing this product, the NanoKVM and this company's irresponsible attitude towards their product's security and their customers. I presume you are an intelligent person, so let us stay focused on the issue at hand and not invent some irrelevant hypotheticals about other companies doing equally irresponsible things to their customers with their products. Again, please do focus, the product we are discussing is NanoKVM.

Secondly, the issue that people like myself and @apalrd take is that unknowing customers (not "network pros" as you call one segment of respondents herein) will have their network security placed at risk. This does not mean there stands absent any mitigation methodologies that they or anyone could ostensibly leverage. However, even in such a scenario whereby one presumes that your postulate is true, the responsibility for a poorly designed product and obstinate style of attitude toward remediating security concerns still falls squarely upon NanoKVM and its developers, as they openly admit and defend their deficient security posture. It is not as if they said, thank you for pointing out those deficiencies we will work on remediation patches as briskly as we can bring them to market. No, they justified their deficient code. That creates a situation wherein people are left with zero trust for them even if they actually do eventually make an effort to effectuate the publication of patches intent upon closing these obvious security flaws.

A tertiary point is, that any potential legal liability of knowingly manufacturing a defective product and continuing to do so with zero concern is not eviscerated simply because you say there are other defective products within the market or the customer can overcome the shortcomings with other hardware and configuration techniques.

Cheering on some other poster's example that seems happily argumentative to you is not the way to participate in the future development of this product and pushing the manufacturer towards being a more responsible manufacturer of network hardware. What you are in fact doing is providing cover for these nitwits.

I am not going to purchase this product nor would I recommend it as @apalrd is 100% correct in his assessment. However, I do use an open source product that takes security seriously, the PiKVM. It is a far superior product and is not that much more expensive. Moreover, I do as well pay attention to new technologies and products as they are brought forth into the market and surely this was one that caught my attention via @apalrd having a video on it.

Your would be well served and more principled to ponder the totality of my points in this small disquisition instead of merely cheering on the simplistic and irrelevant musing of a poster unskilled in realizing the depth of the problem at hand regarding this product in the instant case.

Have a wonderful and blessed day.

[n3gwg]

It's GPL. Someone should just fork this and create a community version. I don't have the bandwidth at the moment. But might in a few months.

Nearly all of the stated security issues are in the firmware/OS image, and not the user space application that is open-source.

From my understanding, the OS build sources/process and kernel tree are not open-source, and so it's impossible to build a new firmware image from scratch even if you wanted to at the moment.

I agree though, Sipeed should prioritise open-sourcing the distribution and firmware source so contributors can help fix some of these issues.

@jduncanator,

I do hope that someone analyzes the firmware in pursuance of assuring it is not Linux based and they are not violating the GPL. In as much as this company seems outwardly incapable of being trusted, such an analysis seems a reasonable endeavor for someone to consider engaging in.

[Korenchkin]

i worked with some sw guys,i teached them how to rs485,where to use udp vs tcp etc. , so i understand where nanokvm is,they are probably very young guys and off course the'll defend themselves,but for this price you want 20+ years of experience? they'll get there,i have faith in them,they just need to understand why they should dedicate probably a lot of time/money into this product for sw guys time,so yeah,as @glitchsys mentioned,this is not a product for enterprise,this is hobby,but it has a great potential, devs need some time,it will not be tomorrow,so go watch another video...and of course they should opensource it,because the community will storm it

[n3gwg]

Korenchkin, @Zepan,

Look I don't care how old or how inexperienced the developers are, that is the fault of the company making this product if they hired a bunch of incapable developers. This is a commercial product being sold as such. I did not see a warning on the literature or website saying "Unprofessionally developed by a bunch of teenagers with zero experience beware of bugs and security issues whatever", as if that is indeed the case (as you seem to be aware of who they have working for them), then the company has a legal duty to warn people as far as I understand things.

The salient point is, it is for sale on Amazon, etc... nobody sees this as a hobby project. Hobby projects run on kickstarter and places like that and open source the hardware, designs, etc.. all that is open sourced here is a small amount of the software. Let us call a spade a spade. This entire suggestion that this is a hobby project is a bunch of BS. It's a commercial product that has been released long before it should ever have been as its security quality is low and unacceptable.

The reason that they should dedicate time/money into this project (at least from a network security point of view) is so they are not sullying their reputation by selling an inferior and deficient product or worse placing a product into the market that is defective and could put them in a precarious legal situation for knowingly selling a product that is known to be defective and opens security holes in someones network with zero warnings to the customer. I would say that is more than enough reason to assure that the product is ready for marketing and instantiates a security posture that is impressive instead of shockingly deficient in no uncertain terms. Apparently neither the company nor the developers care about their honor or the reputation of their company or themselves. That is to me stunningly unimpressive and flabbergasting.

However, taking foregoing entirely into context what is most amazing is people are on here defending them as if "oh my gosh we never knew all these bugs were here"...No, they wrote a lengthy treatise on why they knowingly made the choice to offer a product they knew was deficient and defective from a security posture.

When this product is sold to someone that does not read these forums and they suffer a loss from a network break-in not realizing this was actually a substandard product developed by teenage developers with zero experience or whatever you meant to imply, they will not be happy and if lawyers get involved the project and its company could well end up in hot oil. Is that not a perfectly good enough reason to not allow a knowingly defective product from entering the market or at least conducting a recall or warning all its purchasers. No, the company is defending their poor choices indignantly.

Lastly, please consider what @Zepan implied that it was an intentional and deliberate choice to have these security issues as they are, thus I again call BS on your inexperienced developer assertion anyway.

[Korenchkin]

yes,i definitely get what your issue with nanokvm,i never expected anything security-related from it(i was keeping an eye on this for some time),so the problem is simple-there is no warning it is early development/they present it as a complete product...i would not expect those bugs in pikvm

for me it is hard to be in your position,since i can translate this into any other product(like i mentioned cheap ip camera,or maybe network-connected plant watering),i would think of them the same,that it is security threat and you don't want it on the same network,so this is why i don't get the rage,for this price it is a godsend..

let's take another comparison,you bought tatu(sorry) and expect wv(again sorry)...this is my take...

and yes,reputation is gained,you are acting like they had a good reputation and are losing it?for me they had some reputation(as a good hw company),but nothing i see that can cause loss because of cra**y software still in development(hello win11)
and also,i have yet to see hacked nanokvm(or backdoor in use)
so,am i defending them,or not having any ilusions?

tldr:
so maybe the only thing is missing is warning about software in (early) development (somewhere visible for basic users, probably main page here: https://sipeed.com/nanokvm ),and maybe some information about opensourcing it(time/reason) , would that be enough to drop the rage?

and still no,not associated with nanokvm,i just like the idea (that will take some time to polish)

[alexisfrjp]

You guys are the reason companies don't share their code.
You just want irrelevant reasons to complain, it's completely the opposite mindset of open-source.

It's really a shame.

[byrevx]

Long awaited and here it is:

Update 2025.02.19
All components of NanoKVM were open-sourced, including the front-end, back-end, kvm_vision, kvm_mmf, kvm_system, the kvmapp update package, system sdk, and packaging methods.

[n3gwg]

Long awaited and here it is:

Update 2025.02.19 All components of NanoKVM were open-sourced, including the front-end, back-end, kvm_vision, kvm_mmf, kvm_system, the kvmapp update package, system sdk, and packaging methods.

I did not realize this until now, but that surely is good news. However, things like the code found in libmaixcam_lib.so using custom instructions...now that is surely quite scarey.

At any rate, I think I trust more things like the PiKVM and perhaps the JetKVM when it comes out. Good luck to everyone who thinks stuff is just innocuous stuff, I violently disagree with the assertion. This is not a product to be purchased if you care about security whatsoever.

[luigi311]

I did not realize this until now, but that surely is good news. However, things like the code found in libmaixcam_lib.so using custom instructions...now that is surely quite scarey.

libmaixcam_lib is no longer used based on their changelog https://github.com/sipeed/NanoKVM/blob/main/CHANGELOG.md

[CMCDragonkai]

How does this impact the NanoKVM USB variant? Does it also have these issues like the microphone?