Page 2 of 2

Re: strange bytecode idea...

Posted: Thu Mar 05, 2009 4:48 am
by Combuster
There's still the data flow analysis method, although kindof brute force :wink:

Re: strange bytecode idea...

Posted: Fri Apr 24, 2009 2:24 pm
by earlz
Yea.. old post but I had to revisit this and decided I have a sane idea.

use a half-address range type thing for the bytecode execution. IE, it can access only the top half(or bottom half, depending on flavor) so that all that must be done for type checking(making sure we don't write over kernel memory) is and address,0x7FFFFFFF

So ok.. lets just say we have a lower half kernel that runs programs at 0x80000000(via paging, in ring0)
It doesn't hurt if a bytecode app can somehow hack and get read-access to what it is executing, so we can mark appropriate executable pages as read-only.
so then all we have to do to ensure that it can never access anything outside of it's address range is
or address,0x800000000
This will set the top bit of the address so that it never has access below it's execution mark.

anyone have any commentary about this?

also, for the register bit. I'm still a little stuck. I can tell that memory-registers are not the answer though. And local variables sound nice but I'm not sure about it.. would that say I could do something like:

Code: Select all

_func1:
creat 4 ;creates a new local variable on the stack of size 4
mov l0,0xF00D ;moves 0xf00d to local variable 0
push l0 ;push the value so the called function can't change it
call _func2

_func2:
;what here? how should access be given to the pushed value?