20.10.8: addx/what Intel calls
Control-flow Enforcement Technology:
10.8, 10.9, 10.14: addx/protecting the call stack:
[@] was addx/soa/getting more efficiency along with safety/protecting the call stack
. real opportunity starts with real documentation .
20.10.8: addx/what Intel calls
Control-flow Enforcement Technology:
10.8, 10.9, 10.14: addx/protecting the call stack:
[@] was addx/soa/getting more efficiency along with safety/protecting the call stack
20.9.25: addx/soa/
getting more efficiency along with safety:
10.19: summary:
. soa (service oriented architecture)
is expensive when it intervenes
every call to a subprogram;
instead of calling soa mgt for every call,
we shouldn't be worried about an app making
internal calls to parts of the same app
by the same author with the same privileges.
. a complement of soa controlling the calls,
is stack isolation controlling the returns.
20.10.28: adda/lexicon/this, self, returned:
a discussion about adding keywords to the language.
'20.11.3: co.quora/adds/cyb/sec/total formal verification is not possible in 2020:
current efforts at formal verification
cannot yet find all unknown vulnerabilities in software:
. as pointed out by the SeL4 team, in
“What is Proved and What is Assumed”
who used formal verification to debug a microkernel,
they are still vulnerable to inaccuracies of the hardware model;
ie, assuming the hardware acts a particular way
when under special conditions it actually does something else.
. some CPU chip instructions are reprogrammable by the manufacturer
with on-chip microcode; eg Intel Microcode
(https://en.wikipedia.org/wiki/Intel_Microcode);
this could either make the CPU more correct
or make it vulnerable to malicious modification?
. also, there was some of the SeL4 software
that was not practically verifiable yet:
"there may still be faults remaining in
specific low-level parts of the kernel
(TLB, cache handling, handwritten assembly, boot code)."