MSI C236A Workstation Is A Great Skylake Xeon Motherboard For Linux Users

[phoronix]

Phoronix: MSI C236A Workstation Is A Great Skylake Xeon Motherboard For Linux Users

For the past month and a half I've been battering the MSI C236A Workstation motherboard with an arsenal of benchmarks and various workloads on Linux and BSD. This MSI motherboard for Xeon E3 v5 "Skylake" processors has been working out great.

http://www.phoronix.com/vr.php?view=23056

[Techwolf]

What about linux drivers? A problem I run into on mid and high end MB is they do work with current linux drivers, but only in genertic mode and is missing some of the advertized features.

Would like to have a price chart for all those CPU you tested on that board. Been looking at switching from AMD to Intel due to AMD lack of DDR4 and PCIe 3.x. On Intel side, lack of ECC memory support.

[ruthan]

For me board with 1 socket Xeon is missing point, im paying extra money because i want to use dual socket workstation..

[ermo]

Michael:

Does the motherboard in question support ganging together all CPU cores at their Turbo Boost clocks (essentially a cheap, factory-validated OC functionality)?

My current ASUS P8Z77V LE motherboard can do this with i7 CPUs and I figure that it'll make it more attractive to get one of the cheaper Xeon E3v5 CPUs and spend the remaining cash difference between it and the E3-1280V5 (up to $400!) on a better GPU instead?

[torsionbar28]

Would like to have a price chart for all those CPU you tested on that board. Been looking at switching from AMD to Intel due to AMD lack of DDR4 and PCIe 3.x. On Intel side, lack of ECC memory support.

I had similar thoughts recently, until I saw the price tag on intel CPU's. Intel is definitely price gouging right now, knowing that AMD won't be competitive in the workstation market until Zen. Personally, I don't see much value in building a new Intel system right now. Unless your requirements are such that you need it right-now-today, the price/performance (for both Intel and AMD chips) is going to be a lot better this time next year.

The thing I don't want, is to spend the sky-high sky lake price, and then in 12 months, have the AMD Zen hit the scene with up to 32 cores, DDR4 3200, etc. at a very competitive price, making me regret the barely 1 year old overpriced intel build. I'm still on the Opteron 4386 I built back in 2012, which with 32 GB of ECC DDR3-1600, meets my own needs just fine. I'm waiting for the Zen workstation & server chips next Spring to upgrade.

[dibal]

How about accelerated H.265 playing in Linux? Is it supported?

[imperfectlink]

Looks like a rebadged MSI Z170A SLI PLUS.

https://www.msi.com/Motherboard/Z170A-SLI-PLUS.html#hero-overview

[Michael]

Looks like a rebadged MSI Z170A SLI PLUS.

https://www.msi.com/Motherboard/Z170A-SLI-PLUS.html#hero-overview

Except that uses the Z170 chipset where as this has the C236, which is needed for Skylake Xeon support.

[Luke]

I assume the "Intel Management Engine" and it's signed but updatable blob are not a deterrent here? I suppose for a test machine a malicious blob would be limited to screwing with test results, and that would require AMD to be able to patch Intel's blobs or vice-versa for their to be a motive.

Intel's ability to perform a forced update combined with probable keysharing with the NSA would be a dealbreaker for me unless networking is filtered through another machine and all possible IP addresses from which the blob could be replaced are known. Possibly an oddball, 3ed party networking solution combined with encrypted wifi so the motherboard doesn't have the wifi key and the IME doesn't know where in RAM to look for it might work.

Kernel devs might be able to help with this, by finding some way to randomize both where keys are stored and what they look like in RAM. Suppose OpenSSL and Cryptsetup were both to start storing keys broken into multiple obfuscated segements in RAM and only reassembled in some randomly chosen CPU register when used? If all of the AES-NI commands are not used, it would be more difficult for the firmware to even determine when something is being encrypted or decrypted.

If kernel devs know what could possibly be done by malicious firmware to compromise security, then it becomes possible to write kernel code designed to obfuscate targetted data and deny the blob the information it needs for deciding when to do what. For instance a blob known to search system RAM for keys would fail if they keys were kept in discrete card video, a dedicated PCI-E device posing as a tiny SSD, RAM or in a CPU register. The next blob would fix this, but kernel devs would respond in turn in the usual arms race. Obviously the forced updates would have to be blocked, so hardest case is a laptop that ever uses open Wifi. That might require something like filtering the wifi access through a Raspberry Pi stuffed inside the case.

[triangle]

If kernel devs know what could possibly be done by malicious firmware to compromise security, then it becomes possible to write kernel code designed to obfuscate targetted data and deny the blob the information it needs for deciding when to do what. For instance a blob known to search system RAM for keys would fail if they keys were kept in discrete card video, a dedicated PCI-E device posing as a tiny SSD, RAM or in a CPU register. The next blob would fix this, but kernel devs would respond in turn in the usual arms race. Obviously the forced updates would have to be blocked, so hardest case is a laptop that ever uses open Wifi. That might require something like filtering the wifi access through a Raspberry Pi stuffed inside the case.

If you cant trust the hardware, you cant trust the kernel, or anything down the line.
It is kinda sad that new x86 cpu's are spying on us!