Jump to content

KernBlock: Difference between revisions

From EDM2
No edit summary
No edit summary
 
(4 intermediate revisions by 3 users not shown)
Line 1: Line 1:
This is an extended version of the DevHlp_ProcBlock function. Basically, you specify an arbitrary eventid and a timeout. The block may be coordinated with either an acquired spinlock or a mutexlock, as declared by the flags. The lock is released immediately before blocking, and reacquired after returning from the routine, unless the flag bit KEE_BLOCK_NOACQUIRE prevents re-acquiration. The blocked thread will hang in this routine, and can be resurrected by a signal (unless turned off with KEE_BLOCK_NOSIGNALS) or a KernWakeup with the same eventid.
==Synopsis==
==Synopsis==
APIRET APIENTRY KernBlock(ULONG eventid, ULONG timeout, ULONG flags, PVOID lockptr, PULONG retdata);
APIRET APIENTRY KernBlock(ULONG eventid, ULONG timeout, ULONG flags, PVOID lockptr, PULONG retdata);
 
==Description==
This is an extended version of the DevHlp_ProcBlock function. Basically, you specify an arbitrary eventid and a timeout. The block may be coordinated with either an acquired spinlock or a mutexlock, as declared by the flags. The lock is released immediately before blocking, and reacquired after returning from the routine, unless the flag bit KEE_BLOCK_NOACQUIRE prevents re-acquiration. The blocked thread will hang in this routine, and can be resurrected by a signal (unless turned off with KEE_BLOCK_NOSIGNALS) or a KernWakeup with the same eventid.


==Parameters==
==Parameters==
; eventid : Some unique value, which is to be used by KernWakeup to unblock the thread again.  
;eventid ([[ULONG]]) - input: Some unique value, which is to be used by KernWakeup to unblock the thread again.
 
;timeout ([[ULONG]]) - input: a timeout value in milliseconds. 0xffffffff is supposedly infinite wait.
; timeout : a timeout value in milliseconds. 0xffffffff is supposedly infinite wait.  
;flags ([[ULONG]]) - input: One or more of the following flags:
 
::KEE_BLOCK_NOSIGNALS - Ignore signals, i.e. the block can be released only by end of timeout or an explicit wakeup.
; flags : One or more of the following flags:
::KEE_BLOCK_SPINLOCK - The lockptr points to an acquired KEESpinLock structure.
 
::KEE_BLOCK_EXMUTEXLOCK - The lockptr points to an acquired exclusive mutexlock structure.
    KEE_BLOCK_NOSIGNALS
::KEE_BLOCK_SHMUTEXLOCK - The lockptr points to an acquired shared mutexlock structure.
        Ignore signals, i.e. the block can be released only by end of timeout or an explicit wakeup.  
::KEE_BLOCK_NOACQUIRE - Don't reacquire the lock (if lockptr points to a lock at all) when the KernBlock routine returns.
    KEE_BLOCK_SPINLOCK
;lockptr ([[PVOID]]) - input: Used when one of the three *LOCK bits is set: points to the specified lock structure
        The lockptr points to an acquired KEESpinLock structure.  
;retdata ([[PULONG]]) - input: points to a long variable that receives the value passed by the KernWakeup routine. May be NULL, in this case the value is ignored.
    KEE_BLOCK_EXMUTEXLOCK
        The lockptr points to an acquired exclusive mutexlock structure.  
    KEE_BLOCK_SHMUTEXLOCK
        The lockptr points to an acquired shared mutexlock structure.  
    KEE_BLOCK_NOACQUIRE
        Don't reacquire the lock (if lockptr points to a lock at all) when the KernBlock routine returns.  
 
; lockptr : Used when one of the three *LOCK bits is set: points to the specified lock structure  
 
; retdata : points to a long variable that receives the value passed by the KernWakeup routine. May be NULL, in this case the value is ignored.  


==Comments==
==Comments==
The KEE_NOSIGNALS bit looks dangerous to me - you can this way easily produce unkillable processes: Block in an ioctl with this bit set, and a bug preventing the wakeup, and you won't get rid of this process anymore. The three *LOCK bits are exclusive since there is only one pointer.
The KEE_NOSIGNALS bit looks dangerous to me - you can this way easily produce unkillable processes: Block in an ioctl with this bit set, and a bug preventing the wakeup, and you won't get rid of this process anymore. The three *LOCK bits are exclusive since there is only one pointer.
I guess the retdata value us irrelevant for a timeout or an interrupt by a signal (return values ERROR_TIMEOUT and ERROR_INTERRUPT).  
I guess the retdata value is irrelevant for a timeout or an interrupt by a signal (return values ERROR_TIMEOUT or ERROR_INTERRUPT).


[[Category:Kern]]
[[Category:KEE]]

Latest revision as of 03:09, 28 May 2025

This is an extended version of the DevHlp_ProcBlock function. Basically, you specify an arbitrary eventid and a timeout. The block may be coordinated with either an acquired spinlock or a mutexlock, as declared by the flags. The lock is released immediately before blocking, and reacquired after returning from the routine, unless the flag bit KEE_BLOCK_NOACQUIRE prevents re-acquiration. The blocked thread will hang in this routine, and can be resurrected by a signal (unless turned off with KEE_BLOCK_NOSIGNALS) or a KernWakeup with the same eventid.

Synopsis

APIRET APIENTRY KernBlock(ULONG eventid, ULONG timeout, ULONG flags, PVOID lockptr, PULONG retdata);

Parameters

eventid (ULONG) - input
Some unique value, which is to be used by KernWakeup to unblock the thread again.
timeout (ULONG) - input
a timeout value in milliseconds. 0xffffffff is supposedly infinite wait.
flags (ULONG) - input
One or more of the following flags:
KEE_BLOCK_NOSIGNALS - Ignore signals, i.e. the block can be released only by end of timeout or an explicit wakeup.
KEE_BLOCK_SPINLOCK - The lockptr points to an acquired KEESpinLock structure.
KEE_BLOCK_EXMUTEXLOCK - The lockptr points to an acquired exclusive mutexlock structure.
KEE_BLOCK_SHMUTEXLOCK - The lockptr points to an acquired shared mutexlock structure.
KEE_BLOCK_NOACQUIRE - Don't reacquire the lock (if lockptr points to a lock at all) when the KernBlock routine returns.
lockptr (PVOID) - input
Used when one of the three *LOCK bits is set: points to the specified lock structure
retdata (PULONG) - input
points to a long variable that receives the value passed by the KernWakeup routine. May be NULL, in this case the value is ignored.

Comments

The KEE_NOSIGNALS bit looks dangerous to me - you can this way easily produce unkillable processes: Block in an ioctl with this bit set, and a bug preventing the wakeup, and you won't get rid of this process anymore. The three *LOCK bits are exclusive since there is only one pointer. I guess the retdata value is irrelevant for a timeout or an interrupt by a signal (return values ERROR_TIMEOUT or ERROR_INTERRUPT).