Related articles |
---|
Self-modifying code, Function pointers & { Safety, Security} seimarao@gmail.com (Seima Rao) (2014-03-07) |
Re: Self-modifying code, Function pointers & { Safety, Security} kaz@kylheku.com (Kaz Kylheku) (2014-03-09) |
Re: Self-modifying code, Function pointers & { Safety, Security} martin@gkc.org.uk (Martin Ward) (2014-03-14) |
Re: Self-modifying code, Function pointers & { Safety, Security} tenger@iseries-guru.com (Terrence Enger) (2014-03-15) |
Re: Self-modifying code, Function pointers & { Safety, Security} seimarao@gmail.com (2014-03-20) |
Re: Self-modifying code, Function pointers & { Safety, Security} federation2005@netzero.com (2014-04-13) |
Re: Self-modifying code, Function pointers & { Safety, Security} monnier@iro.umontreal.ca (Stefan Monnier) (2014-04-16) |
From: | Seima Rao <seimarao@gmail.com> |
Newsgroups: | comp.compilers |
Date: | Fri, 7 Mar 2014 21:34:15 +0530 |
Organization: | Compilers Central |
Keywords: | question, comment |
Posted-Date: | 09 Mar 2014 12:38:45 EDT |
Hi,
We are used to separation of code from data at the language level.
However, two features disupt security :
i) self-modifying code
i.e. writing to code space
ii) functions residing in data space
Are there safety & security solutions possible for the above two
safety, security holes ?
Sincerely,
Seima Rao.
[The major reasons for self-modifying code historically were for
address modification for indexing and subroutine returns. Index
registers and indirect addressing provide instruction modification as
the instruction is executed, making those modifications go away. For
runtime code generation, there have been a variety of approaches to
controlled addition of code to running programs, which I could dig up
if people care. -John]
Return to the
comp.compilers page.
Search the
comp.compilers archives again.