Intel MPX

Chat about Linux in general

Intel MPX

Postby mike acker on Thu Mar 27, 2014 7:30 pm

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
370-155


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 ).
Home assembled box using ASUS M5A88-M motherboard and x64 AMD Phenom II X4 3.4GHz cpu; 4x4MB DDR3 RAM
User avatar
mike acker
Level 4
Level 4
 
Posts: 355
Joined: Wed Jul 31, 2013 6:29 pm
Location: Kalamazoo, MI

Linux Mint is funded by ads and donations.
 

Re: Intel MPX

Postby Previous1 on Fri Mar 28, 2014 11:01 pm

You might be interested in grsecurity/PaX:

http://grsecurity.net/
Image
Tutorials | cynicaltux
Arch Linux i3wm, 64bit
User avatar
Previous1
Level 4
Level 4
 
Posts: 367
Joined: Sun Dec 01, 2013 11:48 am


Return to Chat about Linux

Who is online

Users browsing this forum: No registered users and 4 guests