Using Linux+dosemu to install Windows
Hello.
Quoted 3 lines · Patrick J. LoPresti
Quoted 2 lines
The only good thing here is that the amount of progs that works on 486 but not on 386 is very minor...
But how annoying when you run into one :-).
I really don't think it is a major advantage to have an ability to pass the first stage of NT install... :)
OKey, I have found the bug. According to this:
http://support.intel.com/design/intarch/techinfo/Pentium/instrefi.htm#89126
AC is cleared by an INT instruction executed in real mode. As this flag resides in the higher word of eflags, it is not saved on stack so it gets lost.
Two attached patches implements that functionality. Then you can safely remove the "BUG" stuff I think. I have failed to find any docs on how the hardware interrupts affects the AC flag but I guess they don't, otherwise it can be used only when IF is not set.
ID flag is not affected so I guess it gets cleared together with AC by mistake.
Quoted 2 lines
Couldn't you just tell people to use $_cpu=(80386) as a workaround? That would have the side-effect of protecting the AC bit, wouldn't it?
Yes, it would. And not, it is not a side-effect, this is the main and almost only difference with 80486 in dosemu.
Quoted 5 lines
Quoted 3 lines
Furthermore somehow it happens that if the signal was received while AC is set, dosemu itself executes with AC set and crashs somewhere in glibc functions due to exception
0x11.Is that not a bug in the emulator design? I mean, shouldn't *all* of the emulator's state be isolated from the emulated machine's?
Right, this is a main design problem of dosemu which is that the DPMI code is executed in the same address space with dosemu. vm86 is separated however. So DPMI code can do everything and if dosemu have root privs, it can be easily exploited by DPMI code.
Quoted 1 line
Would you accept such a patch?
It is not me who accepting patches here, this is what the project coordinators/maintainers does. Visit
dosemu.sourceforge.net
and
www.sf.net/projects/dosemu
to find out who is responsible.
include/cpu.h +4 -0
@@ -198,6 +198,10 @@#define set_TF () (_EFLAGS |= TF)#define clear_TF () (_EFLAGS &= ~TF)#define isset_TF () ((_EFLAGS & TF) != 0) +/* alignment flag */ +#define set_AC () (_EFLAGS |= AC) +#define clear_AC () (_EFLAGS &= ~AC) +#define isset_AC () ((_EFLAGS & AC) != 0)/* Virtual Interrupt Pending flag */ #define set_VIP () (_EFLAGS |= VIP)#define clear_VIP () (_EFLAGS &= ~VIP)
emu-i386/do_vm86.c +8 -0
@@ -506,6 +506,14 @@pic_iret ();break ;case VM86_INTx: +/* +* AC flag gets cleared by the INT instruction and is not restored +* by IRET because it resides in the higher word of eflags and +* hence not saved in the stack. +* However we can't clear it in real_run_int() et al because +* it is not cleared by hardware interrupts (???) +*/ +clear_AC ();#ifdef USE_MHPDBG mhp_debug (DBG_INTx + (VM86_ARG (retval) <<8 ),0 ,0 );#endif
dosext/dpmi/dpmi.c +8 -0
@@ -2240,6 +2227,14 @@pic_iret ();break ;case VM86_INTx: +/* +* AC flag gets cleared by the INT instruction and is not restored +* by IRET because it resides in the higher word of eflags and +* hence not saved in the stack. +* However we can't clear it in real_run_int() et al because +* it is not cleared by hardware interrupts (???) +*/ +clear_AC ();#ifdef X86_EMULATOR D_printf ("DPMI: Return from vm86() for interrupt\n" );#endif
arch/i386/kernel/vm86.c +6 -0
@@ -317,6 +317,11 @@ regs->eflags &= ~TF_MASK ; } +static inline void clear_AC (struct kernel_vm86_regs * regs) +{ + regs->eflags &= ~AC_MASK ; +} +/* It is correct to call set_IF(regs) from the set_vflags_* * functions. However someone forgot to call clear_IF(regs) * in the opposite case.
@@ -471,6 +476,7 @@IP (regs) = segoffs &0xffff ;clear_TF (regs);clear_IF (regs); +clear_AC (regs);return ; cannot_handle:
Quoted 3 lines · Stas Sergeev
Two attached patches implements that functionality. Then you can safely remove the "BUG" stuff I think.
Yes, that looks like the proper fix to me.
Quoted 7 lines
Right, this is a main design problem of dosemu which is that the DPMI code is executed in the same address space with dosemu. vm86 is separated however. So DPMI code can do everything and if dosemu have root privs, it can be easily exploited by DPMI code.
yes, see section three of README.txt:
* Never allow DPMI programms to run, when dosemu is suid root. (in /etc/dosemu.conf set 'dpmi off' to disable)
It is possible to overwrite sensitive parts of the emulator code, and this makes it possible for a intruder program under DOS, who knows about dosemu internals (which is easy as you have the source) to get root access also on non dosemu processes. Because a lot of games won't work without, we allow creation of LDT-descriptor that span the whole user space.
There is a 'secure' option in /etc/dosemu.conf, that allows to turn off creation of above mentioned descriptors, but those currently protect only the dosemu code and the stack, and may be some diabolical person finds a way to use the (unprotected) heap. Anyway, better 'secure on' than nothing.
Quoted 1 line
Quoted 1 line
Would you accept such a patch?
That would be me. Well together with Stas' patch I would accept it.
Bart