Chapter 3/ Hardware Briefing

Table 3.G Variations of the Call Instruction

CALL Type

Example

Real-Mode Machine Encoding

Near direct

CALL mylabel

0xE8 LI ow byteJIhigh byte]

Near indirect

CALL BX

OxFF 0xD3

Far direct

CALLDS:[mviabel]

Ox9A LIP low] [IP high]LCS low]

LCS high]

Far indirect

CALL DWORD PTR[BX]

OxFF OxlF

Near return

RET

OxC3

Far return

RETF

OxCB

byte, such that the resulting jumps can cover more distance (i.e., —32,768 to

+32,767).

Far jumps arc more involved. Far dircct jumps, for example, arc encoded

with a 32-bit operand that specifies both the segment selector and effective

address of the destination.

Short and near jumps are interesting because they are relocatable, which is to

say that they don't depend upon a given address being specified in the result¬

ing binary encoding. This can be useful when patching an executable.

Case Study: Dumping the IVT

The real-mode execution environment is a fable of sorts. It addresses com¬

plex issues (task and memory management) using a simple ensemble of ac¬

tors. To developers the environment is transparent, making it easy to envision

what is going on. For administrators, it's a nightmare because there is no

protection whatsoever. Take an essential operating system structure like the

IVT. There's nothing to prevent a user application from reading its contents;

for

(

adclress=IDT_001_ADDR;

address<=IDT_255_ADDR;

address=addrGss+IDT_VECTOR_SZ,vector++

)

{

pr1ntf("%03d %08p ".vector,address);

//IVT starts at bottom of memory, so CS is always 0x0000

asm