Motherboard Forums


Reply
Thread Tools Display Modes

Re: An idea how to speed up computer programs and avoid waiting.("event driven memory system")

 
 
Muscipula
Guest
Posts: n/a
 
      09-13-2011, 02:19 PM
The only way you can modify the IP - apart from a branch etc - is to
change the return address on the stack. This can be useful if you want
to read embedded data that is placed directly after the instruction to
the call. Fo example you can pass on a null
terminated string

Andrew Sprott
 
Reply With Quote
 
 
 
 
Robert Wessel
Guest
Posts: n/a
 
      09-16-2011, 11:31 PM
On Fri, 16 Sep 2011 22:36:06 +0200, "wolfgang kern" <(E-Mail Removed)>
wrote:

>
>Muscipula mentoioned:
>
>>> The only way you can modify the IP - apart from a branch etc - is to
>>> change the return address on the stack. This can be useful if you want
>>> to read embedded data that is placed directly after the instruction to
>>> the call. Fo example you can pass on a null
>>> terminated string

>
>
>> Yes, I write a assembler for the C-64 computer years ago and one of the
>> built in things was a call to the "Print" function that would get the
>> data following as text and simply return at the end of that text to move
>> on to the next! Made the code look perty!

>
>|In fact I first used this method on my BBC Model B when I made osbyte
>|and osword calls. Very handy.
>
>This text within code method may seem handy or funny on C-64 and
>similar plain stupid code working CPUs.
>
>But it's extremely worse to mix code and data on a modern x86-CPUs.
>(just read the friendly manuals about the matter)



Non-writable data is fine in text segments, although you don't
generally want to intersperse it between instructions inside a
routine. But constants needed by a routine are usefully stored nearby
(and x86-64 adds RIP relative addressing just for that).

It's usually a terrible idea to store modifiable data anywhere near
instructions on a modern processor - because most CPUs have distinct
instruction and data caches, modifying a line cached in the i-cache
usually leads to some extremely expensive cache invalidations.
 
Reply With Quote
 
 
 
 
Andy \Krazy\ Glew
Guest
Posts: n/a
 
      09-17-2011, 12:54 AM
On 9/16/2011 4:31 PM, Robert Wessel wrote:
> On Fri, 16 Sep 2011 22:36:06 +0200, "wolfgang kern"<(E-Mail Removed)>
> wrote:
>
>>
>> Muscipula mentoioned:
>>
>>>> The only way you can modify the IP - apart from a branch etc - is to
>>>> change the return address on the stack. This can be useful if you want
>>>> to read embedded data that is placed directly after the instruction to
>>>> the call. Fo example you can pass on a null
>>>> terminated string

>>
>>
>>> Yes, I write a assembler for the C-64 computer years ago and one of the
>>> built in things was a call to the "Print" function that would get the
>>> data following as text and simply return at the end of that text to move
>>> on to the next! Made the code look perty!

>>
>> |In fact I first used this method on my BBC Model B when I made osbyte
>> |and osword calls. Very handy.
>>
>> This text within code method may seem handy or funny on C-64 and
>> similar plain stupid code working CPUs.
>>
>> But it's extremely worse to mix code and data on a modern x86-CPUs.
>> (just read the friendly manuals about the matter)

>
>
> Non-writable data is fine in text segments, although you don't
> generally want to intersperse it between instructions inside a
> routine. But constants needed by a routine are usefully stored nearby
> (and x86-64 adds RIP relative addressing just for that).


Yes, but, be careful: data in code segments, even read-only data in
read-only code segments, is often useful in code hijacking.

E.g. force a stack overflow, and instead of returning to a data page,
which might, if you are very, very, lucky, have the NX (No Execute) bit
set, instead return to the executable code page - but at the address of
that read-only data item that happens to be equivalent to a piece of
code that you (the user) don't want to have executed - but which the bad
guy can take advantage of.

It is for reasons like this that sole people consider RIP-relative code
a gift to malware.

Yes, RIP-relative makes it easier to relocate code for ASR (Address
Space Randomization). But it also makes it easier to exploit certain
holes, and to write attack code.
 
Reply With Quote
 
Robert Wessel
Guest
Posts: n/a
 
      09-17-2011, 04:14 AM
On Fri, 16 Sep 2011 17:54:14 -0700, "Andy \"Krazy\" Glew"
<(E-Mail Removed)-arch.net> wrote:

>On 9/16/2011 4:31 PM, Robert Wessel wrote:
>> On Fri, 16 Sep 2011 22:36:06 +0200, "wolfgang kern"<(E-Mail Removed)>
>> wrote:
>>
>>>
>>> Muscipula mentoioned:
>>>
>>>>> The only way you can modify the IP - apart from a branch etc - is to
>>>>> change the return address on the stack. This can be useful if you want
>>>>> to read embedded data that is placed directly after the instruction to
>>>>> the call. Fo example you can pass on a null
>>>>> terminated string
>>>
>>>
>>>> Yes, I write a assembler for the C-64 computer years ago and one of the
>>>> built in things was a call to the "Print" function that would get the
>>>> data following as text and simply return at the end of that text to move
>>>> on to the next! Made the code look perty!
>>>
>>> |In fact I first used this method on my BBC Model B when I made osbyte
>>> |and osword calls. Very handy.
>>>
>>> This text within code method may seem handy or funny on C-64 and
>>> similar plain stupid code working CPUs.
>>>
>>> But it's extremely worse to mix code and data on a modern x86-CPUs.
>>> (just read the friendly manuals about the matter)

>>
>>
>> Non-writable data is fine in text segments, although you don't
>> generally want to intersperse it between instructions inside a
>> routine. But constants needed by a routine are usefully stored nearby
>> (and x86-64 adds RIP relative addressing just for that).

>
>Yes, but, be careful: data in code segments, even read-only data in
>read-only code segments, is often useful in code hijacking.
>
>E.g. force a stack overflow, and instead of returning to a data page,
>which might, if you are very, very, lucky, have the NX (No Execute) bit
>set, instead return to the executable code page - but at the address of
>that read-only data item that happens to be equivalent to a piece of
>code that you (the user) don't want to have executed - but which the bad
>guy can take advantage of.



I'll grant you that possibility, but instruction text has that problem
as well. And is probably more likely to contain interesting sequence
than typical literal/constant pools. Obviously having more stuff in
executable pages increases the number of potentially useful sequences,
but the instruction text is already chock full of various combinations
of bytes - *and* long sequences of valid instructions.

>It is for reasons like this that sole people consider RIP-relative code
>a gift to malware.
>
>Yes, RIP-relative makes it easier to relocate code for ASR (Address
>Space Randomization). But it also makes it easier to exploit certain
>holes, and to write attack code.



I'd expect RIP relative addressing to make code injection easier,
though, as it makes it that much easier to create self-relocating
code.
 
Reply With Quote
 
Robert Redelmeier
Guest
Posts: n/a
 
      09-17-2011, 05:10 PM
In alt.lang.asm [FUp set] Robert Wessel wrote in part:
> Non-writable data is fine in text segments, although you don't
> generally want to intersperse it between instructions inside a
> routine. But constants needed by a routine are usefully stored
> nearby (and x86-64 adds RIP relative addressing just for that).
>
> It's usually a terrible idea to store modifiable data anywhere near
> instructions on a modern processor - because most CPUs have distinct
> instruction and data caches, modifying a line cached in the i-cache
> usually leads to some extremely expensive cache invalidations.



Very good points. When performance matters, I try to keep
even RO data away from I-cache read-ahead.

This cache-thrashing might be a performance killer for interpreted
languages (Java[script]) unless CPU designers hardwired a shortcut
from D-cache to I-cache. When last I checked, they had not,
and a 300 clock round-trip through main DRAM was necessary per
cacheline. JIT could help if the lookahead was long enough to
include whole loops. I wouldn't be surprised if emulation was
faster than linewise interpreters.


-- Robert

 
Reply With Quote
 
 
 
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: An idea how to speed up computer programs and avoid waiting. ("event driven memory system") Skybuck Flying Nvidia 53 09-18-2011 08:34 AM
Re: An idea how to speed up computer programs and avoid waiting. ("event driven memory system") Skybuck Flying Nvidia 15 08-15-2011 02:14 AM
Re: An idea how to speed up computer programs and avoid waiting. ("event driven memory system") Skybuck Flying Nvidia 0 08-01-2011 09:53 PM
An idea how to speed up computer programs and avoid waiting. ("event driven memory system") Skybuck Flying Nvidia 4 07-23-2011 04:19 PM
Re: An idea how to speed up computer programs and avoid waiting. ("event driven memory system") Skybuck Flying Nvidia 0 07-22-2011 02:38 PM


All times are GMT. The time now is 10:23 AM.


Welcome!
Welcome to Motherboard Point
 

Advertisment