On Wed, 24 Dec 2025 at 19:09, heasley <[email protected]> wrote: > SMC literally creates a BMC & its s/w version, it is added to many > models, and is unlikely to ever receive an update. Any bugs or holes > are yours to cherish for the duration of the product's life. To name > a few SMC gems: java, OoD java, backdoors, EoL ssh ciphers, ... > > I want the bmc, and a list of features. Minimally, it seems very > reasonable to ask that bugs be fixed, bundled s/w be updated, and an > automatable update procedure be supplied (that does not require > rebooting the host). > > They're super useful for the lab & testing too. > > And, yes, some are cli, but far from all. The gui ones are really > terrible. Not just network gear, all devices.
Fully agree on what it ideally should be and there are some downright broken things, some which require features that current web browsers do not support. But CMP/BMC are not like this, both are proper CLI. So both examples we've had for networking gear, have been good ones. And I don't think 3rd example exists. And yes, it should be just SOC with mostly standard Linux, with kernel modules to offer access to manage the NOS side control-plane and hardware (to power cycle it, to copy data off/on its storage, etc). But let's say we have this, reasonably well done. Now for whatever reason it stops receiving critical software upgrades, and it ends up running insecure OpenSSH or DHCPd and you can't get channel upgrades to it (maybe you can hack it yourself, if you can root to shell and throw around binary packages for sshd, dhcpd, maybe not). I'll still take it, I'll still take the port with old insecure OpenSSH and DHCPd, rather than also deploy RS232 port in the pop. I'll not be happy about it, but I won't lose any sleep, I know that if my security comes to the BMC port not having insecure OpenSSH. I am not assuming my RS232 port is any more secure than insecure OpenSSH port, I am assuming maybe if you inject some weird sequence, you can do HW interrupt to get the CPU to execute some other code. The BMC would connect to some switch and router down the line. These would have ACL that would allow out-of-band access from my managed infra, and potentially also one or two networks that I can access when nothing in my own infra works. Now the attacker has to have access to a specific network or hosts before they can attack that host, I'm just not worried about that. Things are too broken to entertain the luxury of caring about minor things like that, and it is not conceivable for them to become better in my horizon. I sometimes wonder if PSTN switches like DX200 and AXE are reliable because or despite of how they are written. Both basically have their own internal domain specific language which compiles into a more general purpose language. I think Arista is similarly using or at least used to use internal language that compiles to C++. I wonder if this should be encouraged or discouraged. Naively to me it seems like any project that you expect to be alive decades and need hundreds of high attrition developers should use their own programming language per software. I think this makes sense, because the surface area to write code is very limited, even on large projects, you can only throw a very limited number of developers at it, and the cost of those developers isn't actually a meaningful cost in your bottom line. So in addition to having your application developers, you could have a small team consisting both of language theory experts and senior people who came from the application side, who now develop the language itself. The rationale here is that if your language is targeting a single application, you can make tons of assumptions easily. You can make it increasingly easier for application developers to develop applications quickly and make it hard for them to introduce bugs, because you have visibility of where bugs happen, you can ensure there is an easier way to write those things, which will also guarantee correctness at compile time. -- ++ytti _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/[email protected]/message/YBNHODQ45MG2TU33VK3KNWZES2BZJDVA/
