Hi!
17-Авг-2006 12:49 [EMAIL PROTECTED] (Michael Devore) wrote to
freedos-devel@lists.sourceforge.net:
>> Unless found precise reason, there are no assurance, that your patch
>>fixes (not masks) anything and not damages anything else.
MD> It wouldn't damage anything else, but it might mask it. However, permanent
MD> masking is the best we can do without the physical BIOS to test and
MD> research.
tom have such BIOS. He may even make dump of BIOS area, which you may
study. :)
MD> There are other workarounds that have been made for other buggy
MD> BIOS chips. How would you actually fix a BIOS chip on a user's
MD> machine? You can't force them to re-flash it, even if it were possible and
MD> available.
I not say about "fixing BIOS", I say, that we should know the reasons,
what we fix. "BIOS damages flags" is only suggestion.
>> >> > Could just be hitting one word on the stack, i.e. [sp] at INT entry.
>> >> > That
>> And? Why return address isn't damaged? Let me ask again:
MD> The most obvious case would be if a single bit were being tripped and the
MD> bit still matched existing return address or changed it to a benign one
MD> (which could happen if the bit was low). Less obvious case would be if a
MD> particular value or bit pattern at the location triggered or avoids the
MD> overwrite. I could speculate on other potentialities for a long time.
-----
MD> The reason that the stack overwrite doesn't cause failure on the return
MD> address in the first patch, is that it isn't the return address living
MD> there. It's the original AX value stored on the stack with a PUSH AX you
MD> don't see. See the POP AX that follows?
Yes, sorry, I miss it. And yes, I see - there is bad trick (bad -
because it may and should be simplified) to save/restore AX below return
address, whereas this is absolutely useless (old AX value ayway isn't used
later).
MD> So the BIOS routine probably is
MD> trashing AX, but that's the register most likely to be noncritical across
MD> INT calls,
It not used later.
MD> so changing it would seldom cause problems. When the flags were
MD> there at [sp], then the garbage value could easily have fatal consequences.
Interesting, which precise flags changes may cause such problems?
MD> Okay, that explanation works much better for me, and makes a lot more
MD> sense. I was a bit worried about the return address getting munged myself,
MD> but the fact of AX modification is a good reason for why the BIOS bug
MD> didn't keep biting, and the first patched worked.
_In any case_, even if trouble as you explain (trashed AX value), this
should be explicitly commented in source!!! Or, later, when someone else
again updates source (for example, eliminates superfluous "push/pop ax"
around "disable_enable_a20_*" calls), it again may start work wrong on such
buggt BIOSes.
-----
MD> But it is a weird thing. That's why I would prefer the SUB SP change which
MD> avoids having anything critical at the [sp] location.
If reason in this, then I also vote for explicit "push ax/pop ax"
around discussed "INT 15h" call.
>>MD> Plus, I just found out that there exist old compressed DOS programs which
>>MD> avoid the automatic A20 handling of the kernel,
>> Which packer (and/or programs, which packed by this/these packers)?
MD> Very old QuickBASIC program. I actually don't know if it's packed or
MD> exactly what it's doing in its little pinhead, but it does use segment
MD> wrapping. Shortly after startup the debugger showed it
MD> normalized/underflowed a 0F73:0 segment value to an FF74:FFF0 address
MD> pointing in HMA with poor results.
Someone mentions "overlays". May be, this is reason?
MD> Ran the program in an environment where a known problematic EXEPACKed
MD> program worked (8ACROSS), it still failed. Ran it under LOADFIX, it
MD> worked. The evidence is compelling.
Well, I think, kernel can't be infinite amount of "only patches for 3rd
party bugs", especially, if these bugs are rare. After all, there already
exist LOADFIX for this 8ACROSS.
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
