Forum Replies Created
- AuthorPosts
- in reply to: How can I get involved? #1141
Involvement: I would like to offer my services in writing diagnostics for the Mill.
Diagnostics: Although Ivan mentioned test vectors automatically being generated to test the FPGA/silicon that is just a small subset of all possible failure and may not detect non compliance with the INTENDED design.
I consider that diagnostics written by a human with cunning and wild side ideas is better than fully relying on test vectors.
A human looking at the INTENDED design and with deep understanding of the hardware is likely to provide a better test coverage and early detection of inconsistencies in the tool set chain and physical implementation.Diagnostics are both functional tests and stress tests and are run often with parts/system in an temperature chamber ranging from -40C to +125C or more. At lower temperatures the silicon is faster and often fails with logic timing hazards/tolerances not seen at room temperature. Similar for the higher temperature where the expected clock at 10GHz fails, but may manage to run error free at 8GHz.
I would not write diagnostics in C++ as the decomposition can be too vague for a carefully directed probe test.
About Me: I am still working as an embedded system designer: hardware, firmware, software. In my varied computer engineering career I often wrote CPU, memory and I/O diagnostics in assembler starting in the 1970 for the DG NOVA, PDP-11xx and at least 10 later CPU chips like the 68K. The later diagnostics code was done in C, thank goodness.
Len Spyker - in reply to: ASLR (security) #1045
The ASLR is a clever bad aid (software only) to try hold together the feet of clay of all the flawed system OSes that are now far too costly or impossible to fix.
I believe to make a secure system requires a complex ballet between the protective hardware and the supporting software based on simple and clearly understood principles. Each one alone, hardware or software is not enough.
Security through obscurity is not enough.
You are still doomed, even if you are running everything in an very smart Interpreter running from ROM where each byte and address of user code is being validity checked and even with the 200+ times slow down penalty.
My system design maxim (original or not) is “A little bit of (security) hardware beats an awful lot of software any day”.
Regards Len - in reply to: Mill security model: The main attraction #1010
Hello Peter
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.Len Spyker
- in reply to: Mill security model: The main attraction #1001
Hello Ivan
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.
Regards
Len Spyker
Perth Australia - AuthorPosts
