On 11/24/2013 2:00 PM, Theo de Raadt wrote:
Well, I can't say it's the greatest implementation ever, but arguably it
doesn't seem much worse than on my Sun or IBM servers.
[...]
You just cannot compare this to what Sun did, by (almost always) using
a seperate ethernet port. Probably still crap, but at least there was
some attempt to provide isolation.
Actually, my supermicro boxes have a separate dedicated IPMI ethernet
port. Only some, not all, supermicro boards use that stupid bridged
design that shares a single port for both the primary system ethernet
and IPMI ethernet.
Is it still "arguably" fine?
What exactly are we arguing about again? My specific statement was not
that IPMI was "fine", nor even that it wasn't a piece of Swiss cheese;
it was that the supermicro implementation is arguably not worse than
other manufacturers. Of the articles referenced, the majority of the
problems mentioned are in the base IPMI spec, while there were a couple
of issues specific to supermicro, for the most part all vendors of IPMI
hardware have the same underlying issues, and I'm sure other vendors
have their own specific problems as well.
If you want to argue that overall IPMI is a sucky specification, and
vendors in general have done a crap job of implementing it, you'll have
to find somebody else to argue with, because I don't disagree with you.
If you want to argue that supermicro in specific has done to a
significant extent a crappier job, well, I think you need a bit more
evidence.
The exact same IPMI SOL works fine under linux and illumos, so it
doesn't necessarily seem an underlying fault in the implementation. I
guess I could try booting freebsd on it and see if that works.
"works fine"
Yes, the IPMI SOL "works fine". You can configure it to be a serial
console, and the OS boots and functions correctly and successfully.
Whether or not IPMI as a platform is a good idea or a secure
implementation is really orthogonal to whether or not an OS can use a
serial port.
Back on topic to my actual problem, it looks like the IPMI SOL com2 is
actually using IRQ 10 rather than 5, which both linux and freebsd detect:
[ 2.324044] 00:0e: ttyS2 at I/O 0x3e8 (irq = 10) is a 16550A
uart2: <16550 or compatible> port 0x3.8-0x3ef irq 10 on acpi0
I assume even if this were a physical serial port it would have the same
problem, again nothing to do with IPMI. I'm going to try installing off
the vga head again, and then tweaking the kernel to use irq 10 for com2
rather than 5, and hopefully that will let me use the port as the serial
console for the installed OS. If that works, presumably the installer
could be fixed to work too, but that's probably more trouble than it's
worth.
How come freebsd dynamically detects the correct irq, but openbsd has it
hardcoded?
Similar issues exist on Dell BMC, documented elsewhere, you just need
to search.
Yep, IPMI kinda sucks. Not just on supermicro.
In fact it is unlikely that there are PC server-class
machines that have a safe primary ethernet port. It is possible they
all have such problems built in ("oops").
Are you talking about systems where the bmc shares a physical port with
the OS? That's not what I have.
It is really amazing that so many people prefer to remain blissfully
unaware.
Of what? Potential issues with IPMI? No unawareness here… My boxes all
have separate dedicated IPMI ports, all segregated onto a private
network that sees no public traffic. Is it perfect? No. From a risk
management/cost effectiveness assessment perspective for my specific
deployment, is it better than not using it? Yes...
