Windows Server ported to Qualcomm's ARM server chip. Repeat, Windows Server ported to ARM server chip Microsoft has ported its Windows Server operating system to the Qualcomm Centriq – a 64-bit ARM-compatible server-grade system-on-chip. In a move that will pile further pressure on Intel – which dominates the data center market but is already unnerved by AMD's Naples server processor – Qualcomm and Microsoft will today show …
"Since when does MS have ANY expertise in emulation?"
Microsoft have had Arm on x86 emulators for a good few years - and various other emulation examples prior to that. Perhaps you should use Google before talking rubbish. See for instance: https://www.microsoft.com/en-us/download/details.aspx?id=5352
They have already publicly stated they are porting some version of Windows onto the Qualcomm Snapdragon 835, most likely some sort of ultra-mobile or tablet. So this seems like a logical step.
Unlike the last half arsed effort (the RT), they seem to have actually thought about it and are using an built in emulator to run x86 programes
Will this mean we can get a server with a genuinely open BIOS so we have a bit more trust?
OK, it is obviously possible for the chips themselves to run opaque and suspect code (*cough* Intel SMM *cough*) but having some insight and control over the boot process would help a lot.
Since ARM systems come from a whole different ecosystem, one based on memory maps and fixed hardware designs, basic operations and enumerated buses are likely to be approached from a whole other angle, one that may see something completely different from a BIOS like x86 does. After all, PC-based Macs didn't have to wrestle with that kind of stuff and went straight to EFI, just to name an example.
Having said that, you can't be sure there isn't some kind of uber-root mode hidden in ANY kind of system, regardless of the architecture. Indeed, they may reside in an even lower level than that: say in the network chips.
>Having said that, you can't be sure there isn't some kind of uber-root mode hidden in ANY kind of system, regardless of the architecture. Indeed, they may reside in an even lower level than that: say in the network chips.
I question your expertise in this area, sorry, mate, but what do you mean by uber-root ? network chips ? That's at best ring 0, mate. SMM is in the chipset, ring -2. Nobody knows what that code does, can do anything, everything, undetected, it could probably even fool EFI, BIOS, all other rings such as Windows kernel/user mode, eg wireshark, if ws is running on the same server. Cannot fool wireshark running on a different box, ok, but still ...
Interesting reads:
https://www.theregister.co.uk/2015/08/11/memory_hole_roots_intel_processors/
https://en.wikipedia.org/wiki/Protection_ring
https://en.wikipedia.org/wiki/System_Management_Mode
And SMM can directly poll the network chip, meaning it can be drawn into the same ring.
And as for pwning the network chips, that doesn't even involve rings. It can be considered a Layer 1 (PHY) exploit that doesn't even need to get the CPU involved (remember, most devices have their own controller chips which are essentially localized CPUs), especially if like most network devices they can directly access the physical memory through DMA.
As for fooling Wireshark running on a different box, use a "Wolf in Sheep's Clothing" trick. Wait for an encrypted connection, insert your stuff into that connection, as the destination address isn't that important (the plods will be controlling upstream routers that can intercept the packets regardless of their destination), and since all the packets look the same (encrypted with the same destination) Wireshark won't be able to tell them apart.
In the worst case scenario, an evil network card (or other hardware gizmo) can read/write all memory and have other hardware do stuff. This is basically what SMM can do as well. In fact, with SMM you can generally detect the fact that the CPU is doing SOMETHING in SMM from software. Not so easy if it's coming from hardware.
And rogue hardware can often even replace the actual code in SMRAM that runs in SMM in case it would prefer to do its evil deeds from there.
Except we're talking below that. As in what boots u-boot? That's the kind of thing I'm referring. In the PC world, the power-on points the CPU to the BIOS or EFI which usually takes care of the initial boot. Thus why splash screens and so on. As I understand, in most ARM setups, the initial boot target works somewhat similarly, aiming for a mapped memory location: a specific region of memory usually linked to a ROM to provide the first-stage bootloader which goes from there. It's a sort of "Your Mileage May Vary" thing, but it's enough to point out that there's a different set of legacy baggage with ARM systems than with x86 systems.
There are open source versions of u-boot, but that just pushes the problem down into hardware. How do you know you can trust Qualcomm's server chip?
You also must worry, can you trust the compiler you are using (i.e. Ken Thompson's Reflections on Trusting Trust) Someone built the GCC version you are using, and if you use it to recompile GCC from clean source, that's no guarantee the result isn't compromised.
If you are paranoid, ARM servers will not quiet your paranoia :)
"You also must worry, can you trust the compiler you are using (i.e. Ken Thompson's Reflections on Trusting Trust) Someone built the GCC version you are using, and if you use it to recompile GCC from clean source, that's no guarantee the result isn't compromised."
There are ways to deal with that, too. There's been a rebuttal to that paper that describes a way to use cross-compiling to detect a rogue compiler. But again, a rogue compiler is the least of your worries if you have to deal with compromised but patented high-performance hardware (meaning no alternative suppliers available) forced upon us by hostile sovereign state actors. At this point, it's not possible to have a completely-open high-performance system design (which you need often in servers). Too much of the low-level stuff is still protected.
"""
You also must worry, can you trust the compiler you are using (i.e. Ken Thompson's Reflections on Trusting Trust)
"""
does not address exactly this point, nevertheless
TCCBOOT: TinyCC Boot Loader
(http://www.bellard.org/tcc/tccboot.html)
"TCCBOOT is a boot loader able to compile and boot a Linux kernel directly from its source code."
pointless point ... Most CPU cold start at a known fixed address .. flash, prom, blah blah .blah . You want boot a Windows OS provide a memory environment that makes it look like a Intel turd .. pcbios shown by dmidecode cli. Linux ignores most of that pcbios crap I believe .
It's still 'open source' even if you are prohibited from doing certain things with the source, such as compiling (or synthesizing) and selling the result. And the original commentard was interested in reading it, or perhaps synthesizing it for his own use.
No idea what the license actually says about derivative works and what your buddy did to get a nastygram though.
The drives might actually be hot-swappable. Given their location, you'd need to take the lid off, granted, and probably slide the whole thing a long way out of the rack, but those issues simply make changing drives while the server is running inconvenient, not impossible.
The drives might actually be hot-swappable. Given their location, you'd need to take the lid off, granted, and probably slide the whole thing a long way out of the rack, but those issues simply make changing drives while the server is running inconvenient, not impossible.
In that case I would have mounted the disks at the front so you'd only need to slide it out halfway (that is, the ones not already in hot bays in the front, I'd use that for the boot & OS disks), but that does require a change of airflow management.
I like the idea, even though it's a bit Heath Robinson in approach, a sort of poor man's 1U hot swappability :).
And there is absolutely no point showing off the software port if it's just going to be shelved and forgotten.
So, not like Windows NT for DEC/Alpha or MIPS then? ;-)
We'll have to see what the server market makes of this but ARM-based notebooks would be a welcome change at the lower end of the market where both the price of the Intel chip and the Windows licence eat into margins, meaning that manufacturers are even more likely than usual to cut corners with shit components.
Up-vote for some quality trolling. But you forgot to mention Windows RT... :)
Still, it is a jolly good thing to have diversity in CPU use (as for OS) as it tends to result in more portable future-proof code, reveals bugs quicker, and makes run-everywhere exploits a touch harder. And that is before we get in to the obvious benefits of a genuinely competitive market on price and service!
Even if MS develop the ARM server market primarily for their own cloudy usage, everyone benefits.
>Up-vote for some quality trolling. But you forgot to mention Windows RT... :)
Not trolling I think. It was obvious RT wasn't going to work - not for technical reasons, but the licensing would be a nightmare. Customers wouldn't want to pay license fees for low-powered CPUs and MS wouldn't want to reduce license revenues when they could just kill the product instead. Add the lack of third-party products and an immature hardware platform and you have a doomed product.
On the other hand, Alpha/MIPS ports were killed because MS couldn't be bothered. At the time, these systems were at the higher end of the performance spectrum. Now notice that MS can't be bothered with Windows on ARM on portable devices and you'd be forgiven some scepticism about the product's longevity.
My guess is that this would be for Azure use where MS can control the whole thing and not worry about sales, but mostly it's insurance in case ARM takes off.
The metalwork at the front of the chassis shows 2 full height and one half-height PCIe type cutout. This is the only logical place for them given the fans and PSU's take up the whole back of the chassis
One of the front cut-outs looks like is a drives vs expansion trade-off as is common in small form factor servers.
Given that its an Open Compute machine, I expect that the current Linux builds for Qualcomm processors will run on it - and if not, then I don't expect it will take the OC community long to sort out any bumps in the road.
Agree with the other posts - it makes sense for it to use u-boot as that's well established and reliable.
none of the air flow reaches the processor
It's ARM, not Intel ;-)
Even so, do current ARM chips not even need a heatsink?
Nor do I see any PCI slots.
Two motherboard slots with risers fitted clearly labelled PCIEX3 and PCIEX4 and, as others have pointed out, cutouts on the rear (front) of the case.
I also notice a USB B port on the motherboard - maybe something to do with it being an evaluation board?
And two SD card slots just next to it. What are they likely to be for? Are they normal in a server (I have very little experience of servers). As installed in the case shown they are inaccessible.
M.
And two SD card slots just next to it. What are they likely to be for? Are they normal in a server (I have very little experience of servers). As installed in the case shown they are inaccessible.
They are used in X86 servers for hypervisor bootup (VMWare), could install Linux on raided SDHC cards and then use all the disk slots for data drives.
Is always welcome.
It might be interesting if an ARM CPU chip just plugged into a motherboard to change it. I suspect it could be difficult, but it could be done. Just have a way of switching the BIOS from one ISA to another (which half of the chip would you like today?).
Now if they would make a 68000 speedy chip that would do the same...... (*SIGH*).
> "MS running on Arm"
This actually makes sense for microsoft's server software. An ARM windows laptop, not so much - another Windows RT flop there I think.
Either way, intel stockholders should probably be worried. They have been taking money hand over fist from the cloud market for a while and that stranglehold seems to be coming to an end with this and AMDs latest efforts.
I'm sure Microsoft will use this to try to drive down the price that they buy Intel processors for Azure. After all, it wold be a shame if they lost one of the larger Cloud platforms to another processor.
Whether it will make Intel processors any cheaper for the rest of the world, well, we'll have to see.
I think the Ryzan announcements may do more to Intel's pricing than Windows on ARM, however.
The only reason that .NET on Linux is cut down is that it's living on top of a different OS environment that is incompatible with a lot of the library code. There's no reason they can't compile the full stack if Windows is the host (though they will need a new JIT compiler).
This is much hype about nothing.
What is the performance per watt rating comparison of Intel versus ARM SocS like Cavium and Qualcomm ?
If you ask any data center operator the most important thing is performance per watt.
From my experience, when ARM processors attempt to catch-up with the Intel SPECint rate per thread performance their power consumption shoots up way over Intel CPU's power consumption(atleast 2X). Intel Broadwell TDP is very difficult to beat and in data centers this becomes a huge problem for ARM processors. In addition when you pack 32+ cores in single chip and all the cores start doing memory transfers, the memory channels will saturate in only 16 cores. So there is no real advantage of having 32 core chip for memory bandwidth hungry apps. In fact it is bad thing to have so many cores in a chip for those apps.
Another important things these ARM vendors never tell you is floating point performance of all ARMv8 cores is very bad compared to Intel. In most of the real life workloads the floating point performance matters and Intel is unbeatable in that category so far. The HPC customers may augment their systems with GPUs and FPGAs but most of the data center customers don't do that although it has started to change . Even if GPUs and FPGAs are used in increasing number, the ARM CPUs don't provide any advantage over Intel . So the only thing Intel has to do to maintain its market share is lower its price. This will surely drive all ARM server vendors out of business because their only offering so far is lower price.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
