> Besides all answers given already, one of the reasons Unisys keeps selling Burroughs, aka ClearPath MCP, is its security model.
I think you are exaggerating that selling point – maybe historically that was true, but nowadays nobody is running MCP because it is more secure than any alternative, they are running it because it is a legacy system and migrating off it is too hard or expensive (at least for now), or the migration project is still underway or stuck in development hell, or they tried migrating off it before and the migration project failed.
People who are shopping for the highest security money can buy would be looking at something like BAE Systems XTS-400, not Unisys MCP. (Or seL4, which is open source and hence free, but you'll spend $$$$ on the custom work required to make it do anything useful.)
Especially since MCP now runs as a software CPU emulator under x86-64 Linux, and Unisys has done a lot of work to enable Linux and MCP processes to seamlessly talk to each other – so you can create hybrid apps which retain the MCP core but add components written in Java/etc running directly under Linux – that makes it really hard for contemporary MCP to provide much more security than the host Linux system does.
Maybe, but then again, those systems are based on a systems language that the industry has spent 50 years mostly ignoring its design flaws, until governments decided it was about time to start taking liabilities in cybersecurity seriously.
Also I didn't came up with this myself, it is part of their marketing materials and white papers.
Finally, if it was worthless they would have probably dropped it by now.
> Also I didn't came up with this myself, it is part of their marketing materials and white papers.
> Finally, if it was worthless they would have probably dropped it by now.
Companies love to "talk up" their products in marketing materials. It is far from uncommon for those materials to contain claims which, while not entirely false, aren't exactly true either – and I suspect that's what's happening here.
IBM does the same thing – listen to some IBM i person tell you how "advanced" their operating system is compared to everything else – sure, there's some theoretical truth to that, but in practical terms it is more true in the past than in the present
The CPU emulator part got me thinking, because Burroughs B5000 never was bare metal anyway, rather it was also one of the first bytecode based OSes, so it isn't really emulation when running on the Libra systems.
That would like saying Java/Android and .NET applications, or IBM i, are running under an emulator, even though technically a dynamic compiler is a form of emulation.
I think there is a big difference: the original hardware, the “emulator” was in the CPU microcode - so very close to bare metal, and was narrowly targeted to only do what it needed to do.
Compare that to a software emulator running under a commodity general-purpose operating system-it is a lot further from the bare metal, once you consider all the layers in-between (the OS kernel, libc, etc), the trusted computing base is a lot larger: its size has grown dramatically, being general-purpose includes lots of features the emulator doesn’t need or use - so from a security viewpoint, this is in some respects a step backwards - even though made necessary by economics, and simultaneously has some practical security benefits - although the general purpose OS may be theoretically worse from a security perspective, it receives huge amounts of attention, which helps keep it secure; a rarely used proprietary platform, whatever its theoretical advantages, doesn’t receive the same attention, making it more likely vulnerabilities may lurk undiscovered
BAE STOP 8.8.2 completed Common Criteria security evaluation in September 2023. [0] The evaluated configuration was a BAE XTS-752 machine which uses an Intel Xeon Gold 6256 CPU (Cascade Lake, released 2020, 12 cores), although the evaluation says that the STOP operating system is supported on any "x86 CPU(s) supporting the x86_64 instruction set and features (Intel™ Core™, Intel Xeon or AMD™ x86_64)"
Unisys MCP now runs on Azure, so it would run on whatever Azure uses.
I think both work on commodity x86-64 server hardware; in BAE STOP's case, you need to use the exact hardware in the security evaluation for that evaluation to fully apply; otherwise, you may need to do further analysis and get approval to deviate from it, depending on the policies of the client organisation.
Unisys MCP lacks Common Criteria evaluation (unlike say Red Hat Enterprise Linux), so even if you believe it is more secure than mainstream alternatives, there is no evidence any third party has done any security evaluation to confirm that. (Maybe some really old version did receive a security evaluation, but that has limited relevance to current ones.)
I think you are exaggerating that selling point – maybe historically that was true, but nowadays nobody is running MCP because it is more secure than any alternative, they are running it because it is a legacy system and migrating off it is too hard or expensive (at least for now), or the migration project is still underway or stuck in development hell, or they tried migrating off it before and the migration project failed.
People who are shopping for the highest security money can buy would be looking at something like BAE Systems XTS-400, not Unisys MCP. (Or seL4, which is open source and hence free, but you'll spend $$$$ on the custom work required to make it do anything useful.)
Especially since MCP now runs as a software CPU emulator under x86-64 Linux, and Unisys has done a lot of work to enable Linux and MCP processes to seamlessly talk to each other – so you can create hybrid apps which retain the MCP core but add components written in Java/etc running directly under Linux – that makes it really hard for contemporary MCP to provide much more security than the host Linux system does.