Intel MPX

[mike acker]

Intel MPX
Exerpt:

Intel MPX introduces new registers and new instructions that operate on these registers. Some of the registers added are bounds registers which store a pointer's lower bound and upper bound limits. Whenever the pointer is used, the requested reference is checked against the pointer's associated bounds, thereby preventing out-of-bound memory access (such as buffer overflows and overruns). Out-of-bounds memory references initiate a #BR exception which can then be handled in an appropriate manner.

this kind of stuff fascinates me.

Back on the System/370, in PL/1, when you declared a character string variable you would be given what was called a "dope vector":

Code: Select all

DECLARE CUSTOMER_NAME CHARACTER(30); 

you could declare VARIABLE length if you wanted..... if you did that you had to ALLOCATE the variable before using it

this would seem to be similar to our C code

Code: Select all

char customer_name[31];

but it's not: PL/1 provides a dope vector:

Code: Select all

CNAMEDV DS 0D
CNAMEAD DS A ACTUAL ADDRESS OF THE DATA
CNAMEMX DS H MAXIMUM LENGTH OF CUSTOMER NAME
CNAMECL DS H CURRENT LENGTH OF CUSTOMER NAME

the good thing about this was that if you tried to access data outside of the currently defined area the STRINGRANGE error condition would be raised and if you didn't have an error block for ON STRINGRANGE then the ERROR condition would be raised and if you didn't have an ON ERROR block defined then you were through for the day.

generally we didn't have as many memory over-writes in 370 as we did in 1401s -- because the 370 used a character count in the MVC instruction where the 1401 used a delimiter more like C --- (MCW -- move characters to the word-mark).

I'm still studying LINUX memory management and it still seems odd to me that memory is arranged in such a manner that buffer overflow is still an available exploit. if you put all the text (executable code) on pages marked exec only it should be pretty hard to compromise the text pages in a process space. the area where the stack is seems to be the problem and it certainly seems that if people would just allocate (malloc) their memory instead of declaring it things would be better. still it seems that even when memory is requested via malloc() -- it is provided immediately from an existing page if possible. this may be a simple thing to fix. allocate the stack on its own page and then allocate another page(s) for declared data. all the data areas with initial values would then need to be initialized by executing code rather than depending on initial value statements -- just like you were coding for PARM.LKED=(REUS,...

some of the squinching that was needed on earlier systems might be dropped on x86-64 base systems .

img370-155.jpg

I got a lot of [bad press] at work for writing 370/asm and coding Link-edit overlays but when you working with a 2 MEG RAM memory you have to be creative at times. 2 MEG ( not GB ) . this was the last box I did the system programming for -- it was MVT. ( not MVS ).

[Previous1]

You might be interested in grsecurity/PaX:

http://grsecurity.net/