CE6下的kernelIoControl可不是谁都可以调的

这个可能很多人曾经知道，但是老是忘记，比如我，哈哈。 kerneliocontrol以前在CE5下面耍惯了，用这个接口，AP简直可以无法无天啊，动不动就reset你，哼！who怕who（AP不要kernelicontrol还是可以无法无天，fullkernel啊，哈哈） 最近加了一个CE6下的kerneliocontrol，这种事情不晓得做过多少啦，所以信手拈来。 1.加IOCTL的code定义 2.加ioctl_tab.h里面的table里面code和function的关联 3.加ioctl.c里面function的实现。 4.在AP里面调用kerneliocontrol，参数是code，试图访问这个function 结果发现，AP每次调用kerneliocontrol都是fail，但是参数全部正确啊，晕。 NND，毛了，在function里面加了一堆debug信息，重新出image，哼看你出不出来！ 结果发现，压根没进function。 晕again！第一反应是哪里没有加全或者有代码修改了但是build不到位。 check了n遍，还是不行，开始怀疑自己老年痴呆了！？ 迷茫中突然想到CE6之前不是有篇文章说过，AP不能随便调用kerneliocontrol的。 逐翻出此文（见2楼），发现果然有门道在其中，但是那篇文章不够详细，没有告诉我怎么才能改变权限。 翻了翻BSP(CSP)，果然找到真的有那么一个地方来决定哪些IOCTL的code是允许被AP call的。 PFN_Ioctl g_pfnExtOALIoctl; //------------------------------------------------------------------------------ // Function: IOControl // // Arguments: Same signature as KernelIoControl // DWORD dwIoControlCode: io control code // PBYTE pInBuf: pointer to input buffer // DWORD nInBufSize: length of input buffer in bytes // PBYTE pOutBuf: pointer to out buffer // DWORD nOutBufSize: length of output buffer in bytes // PDWORD pBytesReturned: number of bytes returned in output buffer // // Return Values: // If the function call is successful, TRUE is returned from this API call. // If the function call is not successful, FALSE is returned from this API // call and the last error is set to: // a) ERROR_INVALID_PARAMETER: any of the input arguments are invalid // b) ERROR_NOT_SUPPORTED: given ioctl is not supported // c) any other ioctl set by OAL code // // Abstract: // This is called by kernel whenever a user mode thread makes a call to // KernelIoControl or KernelLibIoControl with io control code being an OAL // io control code. OEMs can override what ioctls a user mode thread can call // by enabling or disabling ioctl codes in this function. // //------------------------------------------------------------------------------ EXTERN_C BOOL IOControl( DWORD dwIoControlCode, PBYTE pInBuf, DWORD nInBufSize, PBYTE pOutBuf, DWORD nOutBufSize, PDWORD pBytesReturned ) { BOOL fRet = FALSE; // // By default the following ioctls are supported for user mode threads. // If a new ioctl is being added to this list, make sure the corresponding // data associated with that ioctl is marshalled properly to the OAL // ioctl implementation. In normal cases, one doesn't need any // marshaling as first level user specified buffers are already validated // by kernel that: // -- the buffers are within the user process space // Check out IsValidUsrPtr() function in vmlayout.h for details on kernel // validation of user specified buffers. Kernel doesn't validate that the // buffers are accessible; it only checks that the buffer start and end // addresses are within the user process space. // switch (dwIoControlCode) { case IOCTL_HAL_GET_CACHE_INFO: case IOCTL_HAL_GET_DEVICE_INFO: case IOCTL_HAL_GET_DEVICEID: case IOCTL_HAL_GET_UUID: case IOCTL_PROCESSOR_INFORMATION: case IOCTL_SET_RTC_WAKEUP_TIME: case IOCTL_HAL_GET_SYS_CLOCK_INFO: case IOCTL_HAL_GET_BTMACADDR: case IOCTL_HAL_GET_CUSTOMERNUM: case IOCTL_HAL_GET_FURTURENUM: case IOCTL_HAL_GET_OEMVALUE: case IOCTL_HAL_REBOOT: // request is to service the ioctl - forward the call to OAL code // OAL code will set the last error if there is a failure fRet = (*g_pfnExtOALIoctl)(dwIoControlCode, pInBuf, nInBufSize, pOutBuf, nOutBufSize, pBytesReturned); break; default: SetLastError(ERROR_NOT_SUPPORTED); break; } return fRet; } 复制代码在case里面的IOCTL是运行被AP调用的，比如上面的IOCTL_HAL_REBOOT。 里面还有一段英文注释，意思大概是，AP调用的kerneliocontrol都会先到这里来集合，通过这里的switch case决定是否允许调用到正真的function.只要把你的IOCTL的code加到case里面，它才能被上层AP访问。 kernel模式的驱动要call kerneliocontrol的话应该是直接调用到真正的ioctl，不需要跑到这个鬼地方来.