- spyker49ParticipantApril 18, 2014 at 4:12 amPost count: 5
My work is in areas like remote control of mining equipment and sub sea oil and gas wellheads and subsea robotics. I develop custom Embedded systems for critical systems.
Have a modest background in computer architecture way back in the 70s.
My main interest in the Mill project is not the CPU stack core. Performance GHz is not so interesting when you are only doing 100 events per second max.
But SECURITY and I mean REAL security is the critical issue in my field.
I consider that buyers will flock to the much more interesting Mill security model.
The Mill CPU stack architecture is a nice but not of itself enough to sway buyers/builders of more secure systems.
I like the Mill security model a lot. I am sure others will too.
Major PLC makers like ABB, Schneider electric, Mitsubishi, Siemens should be contacted, they do need the Mill security.
So many current off the shelf PLC and other embedded boxes with normal chips and Windows or Linux will be, are and have been major hackers and terrorist targets.
The remote break-in into the PLCs controlling the Iran atomic centrifuges and made them many spin to over speed and fail is just one well know example of many other such security failures. But be aware the baddies can do this to you too. See Comp.risk
All industrial countries need truly secure electricity, oil, gas and building security controllers. Not the insecure junk that is on the market now.
I predict that the Mill security architecture and that feature alone is quite enough to get some serious money for some real Mill CPU silicon.
I suggest a simple Mill IC for embedded and PLCs even down to a one stack Mill CPU core at up to 1Ghz but with Full Mill security.
At first glance I consider that the Mill security scheme is somewhat CPU architecture independent. The Mill security IP could be coupled with the upgrades of the IP CPU cores in FPGAs like Altera or Xilinx
Such an high level secure IC or FPGA IP running say Linux could be a big winner in the PLC and embedded market. My best wishes with your success.
- Ivan GodardKeymasterApril 18, 2014 at 10:28 pmPost count: 688
Besides what has been revealed in the talks already, we are actively working to extend and improve the Mill security model. We know that in the long run it will be a Good Thing.
But frankly, we are also worried that in the short run it may not be a Good Thing at all. Far too many programs are out there that are full of security holes that nobody has fallen into yet, or at least they aren’t talking. If the Mill has always-on security (and we feel that security you can shut off isn’t security) then programs will fail on the Mill that “work” on other machines. And Mr. Clueless will be all over the web, posting that Mills are broken because his (obviously bug-free) program works fine on other chips. We wouldn’t survive a reputation for flakiness, deserved or not.
If you think these worries are far-fetched, all I can say is that I remember the transition to MMUs, and hearing people file reports about failing hardware, with comments like “What is this crap about segv?”.
There is a rule of thumb in business, and Mill Computing is a business after all, that for the first sale you must give the user what he thinks he wants, while for the second sale you must have given him (in the first sale) what he actually needed. That makes for subtle design issues. We’ll do our best, and I hope you will be around to balance Mr. Clueless and his rants.
- spyker49ParticipantApril 19, 2014 at 5:43 amPost count: 5
I understand your concerns only too well.
Wasted a day debugging a multiprocessor system looking through a chain of memory windows spanning across 13 PDP-11 (custom variants).
The code was still visible when I powered the target down! What the heck?
Only to realise I had extended the local cache window a bit too large. Oops.
A simply solution for the MR CLUELESS or myself might be to have a couple of IC pins that disable or change modes in the security blob for the developers in the development phase.
Later on in the silicon Fab during the end of a good test pass, the IC test rig blows a few one-time fuses and then it boots and runs in secure mode forever.
I am not an academic type. But great at turning theory into practical bits that work well. You may need more practical people like me who are also good at writing hardware diagnostics and test code.
- PeterHParticipantApril 21, 2014 at 11:49 amPost count: 41
I don’t see the Mill as being inherently much more (or any less) secure than established “large” machine architectures, but as offering low cost access to methods, such as microkernel, that are high cost on existing architecture. The operating system is still in charge of applying the hardware mechanisms, and buggy system utilities may still leave you wide open.
- spyker49ParticipantApril 22, 2014 at 2:10 amPost count: 5
The Mill may or not be more secure the other “secure” systems.
However many current commercial OS do NOT implement or use zero or barely any the hardware security protection that is available for free.
If used properly the hardware security, their user and OS software could run faster.
Why? The 100,000+ of lines of no hardware, security software to “provide protection” against bad software, can be totally eliminated.
Sadly every such flawed OS cannot be fixed easily, because their OS is teetering on a historical pile of insecure weak clay. They need to start for scratch and break 95% of the their very expensive code base.
When the Mill gets up and is fully secure from day one that will be fantastic.
MULTICS reborn. I look forward to that day.
You must be logged in to reply to this topic.