what Intel calls Control-flow Enforcement Technology

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

. computers have a code seg that is readonly 

but it means nothing if the program can write to stack

where the return addresses are stored.

. the call stack has 2 owners 

https://en.wikipedia.org/wiki/Call_stack#Structure

that need protection from each other:

the return address belongs only to the os;

whereas, the local mem of the called subprogram

belongs to the app.

. if the app fails to prevent a buffer overflow

that is caused by bad inputs designed by malware

then the app's modification of the stack 

can overwrite the return address

and cause arbitrary changes in 

what code is executed after subprogram return.

. to avoid giving the app access to the stack,

we replace the locals record on the stack

with a pointer to a record in heap space.

. a return instruction then consists of

returning some heap memory

rather than rolling back the stack pointer.

. a call consists of creating a heap record 

rather than stacking the parameters.

. the os needs to ensure that all apps are 

correctly calling and returning, 

and making no other use of the stack pointer.

20.10.20: protecting the call stack/and the function pointers:

. dividing the stack into control and data partitions

to protect the return address from data overwrites

is not sufficient:

another problem is that most programs require

the use of function pointers

so that they can be decided dynamically

ie, to depend on the current inputs

to decide what order to call subprograms.

. these function pointers are in writable memory

but they represent a form of executable code.

. function pointers need to be replaced

with vars that hold an index into

a table of all possible pointer;

and that table is in read-only memory;

eg, in a code segment rather than a data segment.

. Intel 2016 named this concern

"Control-flow Enforcement Technology".

20.9.11: oop/the essential feature:

. was it true that some people's idea of

pure object orientation required that

every subprogram be a method of a class?

. I'm assuming that the most important feature

of pure oop is that every access of a variable

can happen only indirectly by calling

the methods of that variable's datatype.

10.19:

. actually that is the essential feature of

the abstract datatype;

the essential feature of object-orientation

is not only abstract datatyping but also

letting type mgt decide the subprogram to call

depending not only on the desired function,

but also on the type.tags of the operands;

for instance, when number.type gets

(x.int / y.real)

it sees that the type tags don't match,

so it converts x.int into a real

and then calls real's division on (x,y).