[dingo_bat]

But you can take the OS and write your own driver for your own hardware. Also, you can take the OS as-is, run it on a VM, and examine the packets coming out for signs of any telemetry or any such nefariousness. I think it is a big step ahead of any other switch/router OS.

[kijiki]

None of the current forwarding ASIC vendors publish enough information to write a driver for their chips. So no, you can't write your own driver. The reason OpenSwitch's OpenNSL binary is binary-only is because it uses Broadcom's proprietary SDK, and programs registers that are only available under Broadcom's NDA.

If you're just going to run it in a VM, you'd be better off with more established things like OpenBSD, OpenWRT, pfSense, Cumulus VX, or even just a Debian VM with Quagga.

<disclosure>I'm CTO of Cumulus, whose network OS is exactly as open-source as OpenSwitch: everything but the single user-space program that links to Broadcom's SDK.</disclosure>

[dingo_bat]

>None of the current forwarding ASIC vendors publish enough information to write a driver for their chips. So no, you can't write your own driver.

Of course they don't publish it as open source. But if you buy their chips, they will, I assume. So then you can write your own driver.

>If you're just going to run it in a VM, you'd be better off with more established things like OpenBSD, OpenWRT, pfSense, Cumulus VX, or even just a Debian VM with Quagga.

I agree. My VM scenario was meant only to illustrate that OpenSwitch is really easy to run in a container/VM, and that fact can be used to examine it for any malovalent behavior.

[jlgaddis]

That's not really any different than putting a tap on both sides of one of these NetScreens, for example, and looking at the traffic. It's still impossible to "verify" a device isn't compromised that way.

Only when the public can view (ALL) the code, rebuild it, and install it on their own hardware can we be reasonably confident it has not been tampered with.