flat assembler
Message board for the users of flat assembler.

Index > DOS > TSR with resident uninstaller

Author
Thread Post new topic Reply to topic
SeproMan



Joined: 11 Oct 2009
Posts: 59
Location: Belgium
SeproMan
One of the things to do when uninstalling any TSR is releasing its memory allocation(s) to DOS. I've seen this done by code within the allocation that is to be released. So after freeing the memory there are still instructions left to be executed. This works on DOS because apart from zeroing the owner field in the arena header (the paragraph of memory in front of every allocation) DOS does not tamper with the contents of the allocation.

How safe can a resident uninstaller that works this way be considered?

Imagine an OS more biased towards confidentiality and thus wiping clean the allocation the moment it is released!
Imagine an industrious TSR hooked at the system timer and waiting for an opportunity to get some extra memory!

_________________
Real Address Mode.
Post 03 Aug 2014, 15:39
View user's profile Send private message Reply with quote
ACP



Joined: 23 Sep 2006
Posts: 204
ACP
Aren't you forgetting that DOS has no memory protection and is no re-entrant OS even if you consider INDOS flag? There are billions of ways to actually make the system hang or break it's internal structures...

Basically after freeing memory (using int 21h function 49h) you should return from interrupt ASAP assuming you are calling free memory from your ISR. Nevertheless you shouldn't call int 21h from your timer ISR because you will break something without proper checks Wink

Secondly if you really need more memory why not get away with help of DOS Extender, DPMI or VCPI or XMS/EMS?
Post 03 Aug 2014, 20:01
View user's profile Send private message Reply with quote
axlucas



Joined: 02 May 2014
Posts: 66
Location: Argentina
axlucas
During the execution of your unloading function, if interrupts are disabled (which probably is the case), you could say that it's rather safe to free the memory, but you shouldn't do it by calling int 21h. Instead, first disable whatever triggers your ISR, so that nobody jumps to the free memory area later; then set up registers as if you were going to call the free memory function of int 21h, finally, execute a far jump to int 21h vector. This will free the memory block, but none of your code is left to be executed. When the function ends, IRET will take it back to wherever your ISR was called from and you're done.

I don't have a lot of experience doing this, though, so anybody finding a bug in my idea, please do correct me.
Post 10 Aug 2014, 01:03
View user's profile Send private message Reply with quote
baldr



Joined: 19 Mar 2008
Posts: 1651
baldr
axlucas,

Unfortunately, that may resume execution of interrupted code with corrupted registers.
Post 10 Aug 2014, 16:41
View user's profile Send private message Reply with quote
axlucas



Joined: 02 May 2014
Posts: 66
Location: Argentina
axlucas
Baldr: You're right! I forgot about that. But now I am thinking this: if the TSR is designed by somebody knowning that they are going to call this particular function, they could choose the registers carefully so that the same are used as for the DOS function. That way, there shouldn't be a problem!
Post 11 Aug 2014, 00:06
View user's profile Send private message Reply with quote
ACP



Joined: 23 Sep 2006
Posts: 204
ACP
axlucas
I think you are missing the fact that SeproMan talks about the case of hooking timer interrupt which complicates in DOS compatible systems such cases a lot. There was a good reason why DOS Idle interrupt has been added to the OS in the first place and why Indos flag has been available for so long in DOS (although MS did not document it at the begging).
Post 11 Aug 2014, 09:59
View user's profile Send private message Reply with quote
sinsi



Joined: 10 Aug 2007
Posts: 695
Location: Adelaide
sinsi
Your TSR should have a command line switch like /unload
This lets you tell the resident part to unhook any INTs (if it can), free any extra memory and return a code.
If the code is OK then you can safely free the (inactive) resident part's memory.
Post 11 Aug 2014, 10:10
View user's profile Send private message Reply with quote
ACP



Joined: 23 Sep 2006
Posts: 204
ACP
If I understand the original question correctly this is more race condition issue here since instead of DOS Idle INT, timer interrupt is being used. To make long story short: using timer interrupt for calling DOS function and (re)allocating memory without appropriate precaution taken is always a bad idea.
Post 13 Aug 2014, 18:14
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on YouTube, Twitter.

Website powered by rwasa.