With introduction of 74e527b, a330b56 and subsequently 2791ecd ReactOS can now properly set IOPL (I/O privilege level) for user mode trusted processes. With that said, enable the compilation of raise hard error function call code back.
ProcessUserModeIOPL is strictly implemented for 32-bit architecture so it doesn't make any sense for CSRSS to gather user mode I/O privilege when that won't work anyway.
CORE-17545
subsystems/win32/csrsrv/api.c:63:9: warning: variable 'ServerDll' is used uninitialized whenever '||' condition is true [-Wsometimes-uninitialized]
if ((ServerId >= CSR_SERVER_DLL_MAX) ||
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
subsystems/win32/csrsrv/api.c:67:76: note: uninitialized use occurs here
DPRINT1("CSRSS: %lx is invalid ServerDllIndex (%08x)\n", ServerId, ServerDll);
^~~~~~~~~
Addendum to commit 0a392b18.
The actual problem that existed all along was that the buffers being
validated with CsrValidateMessageBuffer() were not the correct ones!
What had to be checked is the string buffer **INSIDE** the UNICODE_STRING
structures! Indeed, it is these buffers that we are allocating on client side,
see https://github.com/reactos/reactos/blob/9b421af1/dll/win32/kernel32/client/dosdev.c#L324-L336
Dedicated to Pierre Schweitzer.
Since indeeed the memcpy/move type of functions usually don't operate on
pointers to 'volatile' data, don't make ClientCaptureBuffer volatile.
Instead when retrieving the values of its 'Size' and 'PointerCount'
members (see the SEH block), use the so-called technique of "volatile
glasses" [1], where the pointer will be explicitly casted to "volatile TYPE*"
where needed.
[1]: https://docs.microsoft.com/archive/blogs/itgoestoeleven/why-your-user-mode-pointer-captures-are-probably-broken
- Improve capture buffer validation in CsrCaptureArguments(), by
implementing the checks done by Windows 2003 (NT 5.2) described
in section "Server-Side Validation and Capture" of the article
https://www.geoffchappell.com/studies/windows/win32/csrsrv/api/apireqst/capture_header.htm
- In CsrReleaseCapturedArguments(), protect the data copy back into
the client buffer within a SEH block.
Rename inaccurate names 'LocalCaptureBuffer' and 'RemoteCaptureBuffer'
into 'ClientCaptureBuffer' and 'ServerCaptureBuffer' respectively.
(Recall: CSRSRV is the 'Server', and any app doing LPC calls to it is
the 'Client'.)
Also, trigger the less fatal breakpoints only if CSRSS/CSRSRV is being
debugged (the 'BeingDebugged' flag is set in the current PEB). This will
avoid any unhandled breakpoint exceptions when testing/fuzzing running
debug builds of ReactOS without any debugger attached.
This will notably bring support for DOS mapping with LUID devices
(not yet supported in the kernel, though).
This also reduces complexity (and thus memory usage) with the "history"
thing. Multiple targets are stored in the link target as MULTI_SZ string.
This fixes regressions introduced with kernel32 fixes/rewrites.
There is no need to compile our DLLs as shared libraries since we are
managing symbols exports and imports through spec files.
On my system, this reduces the configure-time by a factor of two.
[CMDUTILS/AT] Fix missing translation strings in certain files.
[NOTEPAD] Fix SUBLANG code to brazillian.
[RAPPS] Fix missing translation strings in certain files.
[FDEBUG] Fix translation string ID.
[CPL/INPUT] Fix missing translation strings in certain files.
[ACPPAGE] Fix incorrect resource IDs.
[NETSHELL] Fix incorrect resource IDs.
[DEVMGR] Fix missing translation strings in certain files.
[LSASRV] Fix missing translation strings in certain files.
[RASDLG] Fix missing translation strings in certain files.
[SHELL32] Fix missing translation strings and incorrect resource IDs.
[TAPIUI] Fix missing translation strings in certain files.
[WINFILE] Fix incorrect resource IDs.
[NTVDM] Fix missing translation strings in certain files.
[USERSRV] Fix missing translation strings in certain files.
[BROWSEUI] One more missing string.
[FLTMC] Fix missing translation strings in certain files.
Detected using the TransDiffer tool (early alpha).
This doesn't include everything anymore, but I wanted to get the PR out of the way.
Some applications, run on a CDROM, may attempt to open
a file with write access. CDFS driver will deny such
request in ReactOS (but also in Windows NT). Then, to
restore that behavior from old Windows (9X), our ntvdm,
as Microsoft ntvdm will attempt to reopen the file only
with read access, if opening failed because of denied access
and if the file is on a CDROM.
CORE-15211
