Mail Archives: djgpp/1997/09/25/19:15:25
On Thu, 25 Sep 1997, Eli Zaretskii wrote:
> On Wed, 24 Sep 1997, firewind wrote:
>
> > > [ES cannot be an arbitrary value]
>
> The above is correct, but only when the processor is in protected
> mode.
[snip]
> However, in the context of calling real-mode interrupts, the ES value
> is not a protected-mode selector, but a real-mode segment, which will
> be loaded into the ES register only *after* the processor switches to
> real mode. So in this case, ES can have any value, as no protection
> is available in real mode.
Okay, I feel there's a vital difference between selectors and segments
that I'm missing here... a selector exists only in protected mode, can be
as large as 4GB, and is registered in some global table while segments are
some arbitrary chunk of fixed-length, real mode memory, correct?
> No, ['es' is] the real-mode segment of the DOS internal data. In other
> words, it is the value loaded into DS register when DOS executes its
> code on behalf of some program that requested any of DOS services.
Okay, so again this is due to my segment vs. selector misunderstanding.
(I'm feeling guilty for using all the wrong words in my explanation to
Brett :)
> Get ready for a shock: _far* functions do NOT provide any protection
> whatsoever.
This is in fact what I believed at first.
> The protection is not something implemented by a library function,
> it's intrinsic in the protected-mode operation of the CPU. It is
> important to understand that (at least as far as data access is
> concerned) this protection is solely based on the segment descriptor
> that is loaded when a particular segment is accessed. In particular,
> the processor checks whether the segment limit is exceeded, whether
> you are trying to write into a read-only segment, etc. Any
> ``garbage'' that passes these tests will not be prevented from doing
> its harm.
So if the (supposedly garbage) values of 'es' and 'bx' are outside the
limits, the function fails, otherwise you get a random read(\write).
> So the correct question would be: does `_dos_ds' define a segment that
> guards against garbled addresses?
>
> Sadly, in DJGPP v2.01, the answer is NO!
> [DJGPP v2.01 has a limit of 4GB on _dos_ds but this doesn't help
> anything under most memory managers]
>
> I hope that for v2.02 I will be able to convince The Powers That Be to
> set the limit back to 1MB (+64KB, to enable accesses to the HMA). But
> even then, any combination of ES and BX that yields ES*16+BX which
> doesn't exceed this limit will never trigger any GPF; you just get
> garbled data when you read that address, and risk crashing the system
> if you write it.
Okay, I think I understand now. :) Thanks, Eli. :)
> > [ISRs shouldn't call DOS while InDOS is non-zero]
>
> I won't go into the intricacies of this (it could fill a book), but
> this is mostly, but not entirely true. First, some DOS functions in
> the low numbers can be called while InDOS is set, since they are
> executed on a different stack and therefore don't trigger the
> reentrancy problems if you need to do file I/O.
Yes, I'd noticed this on some browses of Ralf Brown's, but can never
remember which interrupts and aren't brave enough to try it anyway. :)
I'm very careful when messing with such things. :)
late\fw
- Raw text -