[ros-diffs] [ion] 22266: - Change ObpCreateHandle to the one documented and explained in the Gl00my documentation. It also fits the re-factored split create/increment model better, supports open reasons, and allows to do type-checking and extra object referencing from within one routine. - Add code to ObOpenObjectByName to detect the OpenReason. Experimental, since I'm not sure when to clear the flag.
ion at svn.reactos.org
ion at svn.reactos.org
Wed Jun 7 07:37:04 CEST 2006
- Previous message: [ros-diffs] [ion] 22265: - Add some trace macros to monitor handle/pointer counts for fixing regressions/bugs later. - Change ObpCreateHandle to use an ACCESS_STATE structure instead of DesiredAccess. This is to help moving to an updated model where creating and incrementing a handle are 2 operations, so that code can be refactored (similarly to how we now have Delete/Decrement as 2 operations). - Fix functions that were not creating an ACCESS_STATE Structure to create one locally now, or use the one passed as a parameter, if available.
- Next message: [ros-diffs] [ion] 22267: - Final fixes to ObpCreateHandle that I can think of before splitting Create/Increment (might be lacking some security checks or trace/database functionality, but I haven't found any info on the latter, while the former I will stub, but I don't have the skills to imlement (ObAssignObjectSecurity)): * Honour ObjectType passed to the function and fail if it doesn't match. * Use table-based logic instead of process-based logic for Kernel vs User-mode handles (same change that's been done all over the place, since it requires only one dereference of the process object). * Do the GENERIC/MAXIMUM_ALLOWED logic directly inside the ACCESS_STATE structure. * This is where we should call the OpenProcedure (acc. to Gl00my), but this kills win32k -- investigate, #ifed out for now. * Increase the object type's number of handles as well. * Set the handle table entry's ObAttributes correctly; the old code seems to have been messing that up. * Honour the AdditionalReferences parameter and do referencing bias if requested. * Honour the ReturnedObject parameter to return the object pointer back to the caller. * Add OBTRACEing to the function. * If we failed because a handle couldn't be allocated, use the distinguied STATUS_INSUFFICIENT_RESOURCES error code instead of the generic STATUS_UNSCUCESFFUL, and backout all the changes we made by calling ObpDecrementHandleCount.
- Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
Author: ion
Date: Wed Jun 7 09:37:04 2006
New Revision: 22266
URL: http://svn.reactos.ru/svn/reactos?rev=22266&view=rev
Log:
- Change ObpCreateHandle to the one documented and explained in the Gl00my documentation. It also fits the re-factored split create/increment model better, supports open reasons, and allows to do type-checking and extra object referencing from within one routine.
- Add code to ObOpenObjectByName to detect the OpenReason. Experimental, since I'm not sure when to clear the flag.
Modified:
trunk/reactos/ntoskrnl/ob/obhandle.c
Modified: trunk/reactos/ntoskrnl/ob/obhandle.c
URL: http://svn.reactos.ru/svn/reactos/trunk/reactos/ntoskrnl/ob/obhandle.c?rev=22266&r1=22265&r2=22266&view=diff
==============================================================================
--- trunk/reactos/ntoskrnl/ob/obhandle.c (original)
+++ trunk/reactos/ntoskrnl/ob/obhandle.c Wed Jun 7 09:37:04 2006
@@ -353,17 +353,20 @@
NTSTATUS
NTAPI
-ObpCreateHandle(PVOID ObjectBody,
- PACCESS_STATE AccessState,
- ULONG HandleAttributes,
- PHANDLE HandleReturn)
- /*
- * FUNCTION: Add a handle referencing an object
- * ARGUMENTS:
- * obj = Object body that the handle should refer to
- * RETURNS: The created handle
- * NOTE: The handle is valid only in the context of the current process
- */
+ObpCreateHandle(IN OB_OPEN_REASON OpenReason, // Gloomy says this is "enables Security" if == 1.
+ // since this function *has* to call ObpIncrementHandleCount,
+ // which needs to somehow know the OpenReason, and since
+ // ObOpenHandle == 1, I'm guessing this is actually the
+ // OpenReason. Also makes sense since this function is shared
+ // by Duplication, Creation and Opening.
+ IN PVOID ObjectBody,
+ IN POBJECT_TYPE Type OPTIONAL,
+ IN PACCESS_STATE AccessState,
+ IN ULONG AdditionalReferences,
+ IN ULONG HandleAttributes,
+ IN KPROCESSOR_MODE AccessMode,
+ OUT PVOID *ReturnedObject,
+ OUT PHANDLE ReturnedHandle)
{
HANDLE_TABLE_ENTRY NewEntry;
PEPROCESS Process, CurrentProcess;
@@ -446,7 +449,7 @@
ObReferenceObject(ObjectBody);
}
- *HandleReturn = Handle;
+ *ReturnedHandle = Handle;
return STATUS_SUCCESS;
}
@@ -550,11 +553,13 @@
Ret = (HandleTableEntry->ObAttributes & EX_HANDLE_ENTRY_INHERITABLE) != 0;
if(Ret)
{
+ /* Get the object header */
+ ObjectHeader = EX_HTE_TO_HDR(HandleTableEntry);
+
/* Setup the access state */
AccessState.PreviouslyGrantedAccess = HandleTableEntry->GrantedAccess;
/* Get the object header and increment the handle and pointer counts */
- ObjectHeader = EX_HTE_TO_HDR(HandleTableEntry);
InterlockedIncrement(&ObjectHeader->HandleCount);
InterlockedIncrement(&ObjectHeader->PointerCount);
}
@@ -790,9 +795,11 @@
OBJECT_CREATE_INFORMATION ObjectCreateInfo;
NTSTATUS Status;
OBP_LOOKUP_CONTEXT Context;
+ POBJECT_HEADER ObjectHeader;
AUX_DATA AuxData;
PGENERIC_MAPPING GenericMapping = NULL;
ACCESS_STATE AccessState;
+ OB_OPEN_REASON OpenReason;
PAGED_CODE();
/* Capture all the info */
@@ -840,10 +847,28 @@
NULL);
if (!NT_SUCCESS(Status)) goto Cleanup;
+ /* Check if this object has create information */
+ ObjectHeader = OBJECT_TO_OBJECT_HEADER(Object);
+ if (ObjectHeader->Flags & OB_FLAG_CREATE_INFO)
+ {
+ /* Then we are creating a new handle */
+ OpenReason = ObCreateHandle;
+ }
+ else
+ {
+ /* Otherwise, we are merely opening it */
+ OpenReason = ObOpenHandle;
+ }
+
/* Create the actual handle now */
- Status = ObpCreateHandle(Object,
+ Status = ObpCreateHandle(OpenReason,
+ Object,
+ ObjectType,
PassedAccessState,
+ 0,
ObjectCreateInfo.Attributes,
+ AccessMode,
+ NULL,
Handle);
Cleanup:
@@ -910,9 +935,14 @@
}
/* Create the handle */
- Status = ObpCreateHandle(Object,
+ Status = ObpCreateHandle(ObOpenHandle,
+ Object,
+ ObjectType,
PassedAccessState,
+ 0,
HandleAttributes,
+ AccessMode,
+ NULL,
Handle);
/* Delete the access state */
@@ -924,6 +954,7 @@
/* ROS Hack: Dereference the object and return */
ObDereferenceObject(Object);
+ /* Return */
OBTRACE("OBTRACE: %s returning Object with PC S: %lx %lx\n",
__FUNCTION__,
OBJECT_TO_OBJECT_HEADER(Object)->PointerCount,
@@ -1128,12 +1159,15 @@
DPRINT("Creating handle\n");
if (Handle != NULL)
{
- Status = ObpCreateHandle(&Header->Body,
- PassedAccessState,
- ObjectCreateInfo->Attributes,
- Handle);
- DPRINT("handle Created: %d. refcount. handlecount %d %d\n",
- *Handle, Header->PointerCount, Header->HandleCount);
+ Status = ObpCreateHandle(ObCreateHandle,
+ &Header->Body,
+ NULL,
+ PassedAccessState,
+ AdditionalReferences + 1,
+ ObjectCreateInfo->Attributes,
+ ExGetPreviousMode(),
+ NULL,
+ Handle);
}
/* We can delete the Create Info now */
@@ -1260,9 +1294,14 @@
DesiredAccess,
&ObjectType->TypeInfo.GenericMapping);
- Status = ObpCreateHandle(ObjectBody,
+ Status = ObpCreateHandle(ObDuplicateHandle,
+ ObjectBody,
+ ObjectType,
PassedAccessState,
+ 0,
HandleAttributes,
+ PreviousMode,
+ NULL,
&hTarget);
if (AttachedToProcess)
- Previous message: [ros-diffs] [ion] 22265: - Add some trace macros to monitor handle/pointer counts for fixing regressions/bugs later. - Change ObpCreateHandle to use an ACCESS_STATE structure instead of DesiredAccess. This is to help moving to an updated model where creating and incrementing a handle are 2 operations, so that code can be refactored (similarly to how we now have Delete/Decrement as 2 operations). - Fix functions that were not creating an ACCESS_STATE Structure to create one locally now, or use the one passed as a parameter, if available.
- Next message: [ros-diffs] [ion] 22267: - Final fixes to ObpCreateHandle that I can think of before splitting Create/Increment (might be lacking some security checks or trace/database functionality, but I haven't found any info on the latter, while the former I will stub, but I don't have the skills to imlement (ObAssignObjectSecurity)): * Honour ObjectType passed to the function and fail if it doesn't match. * Use table-based logic instead of process-based logic for Kernel vs User-mode handles (same change that's been done all over the place, since it requires only one dereference of the process object). * Do the GENERIC/MAXIMUM_ALLOWED logic directly inside the ACCESS_STATE structure. * This is where we should call the OpenProcedure (acc. to Gl00my), but this kills win32k -- investigate, #ifed out for now. * Increase the object type's number of handles as well. * Set the handle table entry's ObAttributes correctly; the old code seems to have been messing that up. * Honour the AdditionalReferences parameter and do referencing bias if requested. * Honour the ReturnedObject parameter to return the object pointer back to the caller. * Add OBTRACEing to the function. * If we failed because a handle couldn't be allocated, use the distinguied STATUS_INSUFFICIENT_RESOURCES error code instead of the generic STATUS_UNSCUCESFFUL, and backout all the changes we made by calling ObpDecrementHandleCount.
- Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
More information about the Ros-diffs
mailing list