This also fixes delivering APCs from the system call handler, which previously would have clobbered rax. Also don't use the thread's TrapFrame member, which is not always set, when returning.
This is needed, because KiSystemCallHandler can be called multiple times for the same syscall entry, which would mess up the linkage. This replaces a previous hack and makes things cleaner.
In case of failure, ObInsertObject itself dereferences the object, so calling ObDereferenceObject one more time in the failure handler is redundant.
- Remove ObDereferenceObject call from CmpCreateRegistryRoot in case ObInsertObject fails.
- Add missing RootKey dereference if CmpCreateRegistryRoot failed to get the key cell (KeyCell).
CORE-17904
- Use an index for the table instead of ugly pointer offset
- Invert the check for GUI calls
- Fail with proper status code on invalid win32k syscall ids
This is required since while interrupts are enabled, another user APC could get queued and we want to guarantee that those are all delivered before returning to user mode.
A hive whose KCBs have a reference count of 0, meaning nobody is using these keys anymore, will not get removed from the cache table.
As a result during a normal hive unloading operation you will get orphaned KCBs which results in an unload failure.
This is wrong, because this is what a normal hive unloading is supposed to do. What it cannot do of course is that it cannot
scramble the references of opened keys by the users who use the Registry, as it is the job of force unloading mechanism to do that.
Also remove a misleading debug print. Force unloading works as intended by scrambling the references of keys and marking the KCB for deletion,
which is what how a force unload works. Namely Windows does exactly that.
CORE-10705
- Annotate the CmpEnumerateOpenSubKeys function with SAL2
- When removing an orphaned cached KCB, ensure that it is locked before clearing it from cache table entries
Problematic behaviour was added in commit a97f262ed (r26067), and
commit c39812d1b (r46193) converted to RtlUpcaseUnicodeString() call.
This was modifying the caller's given string. This is not really
a good practice to do so just to make display fancier.
For example, IopInitializeBuiltinDriver(), that calls the display
function, also uses the passed ServiceName later after.
Because IopDisplayLoadingMessage() executes only in SOS mode,
uppercasing the ServiceName in one case but not the other would
implicitly modify the observable OS behaviour.
IopSuffixUnicodeString() is adapted to be similar to RtlPrefixUnicodeString().
- Make the boolean SosEnabled from ex/init.c visible globally so that
it can be checked against by IopDisplayLoadingMessage().
- Also use RtlString* function to construct the string.
- Doxygen comments;
- SAL annotations;
- These two functions are local to driver.c file only -> static'ify them.
- 2 -> sizeof(WCHAR);
- Rename Length to NumChars;
- static const'ify the L".SYS" string.
Otherwise the USHORT members are aligned to 4-byte boundary space
which overflows the disk sector buffer and ultimately results in crash.
This can be reproduced by trying to format the USB drive with Rufus.
Also put some additional C_ASSERT checks for extra safety.
On the uniprocessor kernel KiAcquirePrcbLock is a stub that doesn't modify the current Prcb's PrcbLock value.
Quickly protect this assert around CONFIG_SMP
Fixed in x86 and ARM (this was already done in x64).
This is needed because thread preparation routine KxQueueReadyThread()
releases PRCB lock, but does not acquire it, so that the locking must
always be done outside the function, same as in all its other usage cases.
This fixes an assert from release PRCB routine, when booting x86 ReactOS
in SMP mode, because it attempts to release the lock when it is not
actually acquired.
Addendum to commit a011d19ed.
+ Add an assert in KxQueueReadyThread() to ensure the PRCB lock is actually acquired.
CORE-1697
Raise IRQL to SYNCH_LEVEL when exiting from the idle thread in the
idle loop, in case it is scheduled for execution. Then restore it
back to DISPATCH_LEVEL, after this is done.
This behaviour is a bit similar to the way it's done on x64.
This IRQL raise is necessary only in SMP builds.
Calls are placed in CONFIG_SMP ifdef: this avoids unnecessary IRQL
changes on UP, since SYNCH_LEVEL and DISPATCH_LEVEL are identical
there, unlike in MP, where SYNCH_LEVEL is IPI_LEVEL - 2 actually.
This prevents bugcheck DRIVER_IRQL_NOT_LESS_OR_EQUAL when booting
SMP x86 ReactOS, in KiTimerExpiration when calling it 2nd time.
The BSOD happened due to IRQL levels mismatch.
+ Improve related comments.
Registry hives are opened in shared read access when NT is loaded in PE
mode (MININT) or from network (the hives residing on a network share).
This is true in particular for the main system hives (SYSTEM, SOFTWARE,
DEFAULT, ...).
However, in PE mode, we can allow other hives, e.g. those loaded by the
user (with NtLoadKey) to be loaded with full read/write access, since we
boot from a local computer.
In particular remove some extra-parentheses around single code tokens,
and replace few "DPRINT1 + while (TRUE);" by UNIMPLEMENTED_DBGBREAK.
+ Improve some comments.
- Move the GUID_DEVICE_ENUMERATED event from the TargetDeviceChangeEvent category to the DeviceInstallEvent category
- Create a new function that handles DeviceInstallEvent category events
Co-authored-by: Victor Perevertkin <victor.perevertkin@reactos.org>
Introduce the initial changes needed to get other processors up and into kernel mode.
This only supports x86 as of now but is the first real step towards using other system processors.
Sometimes repairing a broken hive with a hive log does not always guarantee the hive
in question has fully recovered. In worst cases it could happen the LOG itself is even
corrupt too and that would certainly lead to a total unbootable system. This is most likely
if the victim hive is the SYSTEM hive.
This can be anyhow solved by the help of a mirror hive, or also called an "alternate hive".
Alternate hives serve the purpose as backup hives for primary hives of which there is still
a risk that is not worth taking. For now only the SYSTEM hive is granted the right to have
a backup alternate hive.
=== NOTE ===
Currently the SYSTEM hive can only base upon the alternate SYSTEM.ALT hive, which means the
corresponding LOG file never gets updated. When time comes the existing code must be adapted
to allow the possibility to use .ALT and .LOG hives simultaneously.
If FreeLdr performed recovery against the SYSTEM hive with a log, all of its data is only present in volatile memory thus dirty. So the kernel is responsible to flush all the data that's been recovered within the SYSTEM hive into the backing storage.
In addition to that, in some functions like CmFlushKey, CmSaveKey and CmSaveMergedKeys we must validate the underlying hives as a matter of precaution that everything is alright and we don't fuck all the shit up.
CmCheckRegistry is a function that provides the necessary validation checks for a registry hive. This function usually comes into action when logs have been replayed for example, or when a registry hive internals have changed such as when saving a key, loading a key, etc.
This commit implements the whole Check Registry infrastructure (cmcheck.c) in CMLIB library for ease of usage and wide accessibility across parts of the OS. In addition, two more functions for registry checks are also implemented -- HvValidateHive and HvValidateBin.
Instead of having the CmCheckRegistry implementation in the kernel, it's better to have it in the Configuration Manager library instead (aka CMLIB). The benefits of having it in the library are the following:
- CmCheckRegistry can be used in FreeLdr to fix the SYSTEM hive
- It can be used on-demand in the kernel
- It can be used for offline registry repair tools
- It makes the underlying CmCheckRegistry implementation code debug-able in user mode
CORE-9195
CORE-6762
During a I/O failure of whatever kind the upper-level driver, namely a FSD, can raise a hard error and a deadlock can occur. We wouldn't want that to happen for particular files like hives or logs so in such cases we must disable hard errors before toying with hives until we're done.
In addition to that, annotate the CmpFileSetSize function's parameters with SAL.
When shutting down the registry of the system we don't want that the registry in question gets poked again, such as flushing the hives or syncing the hives and respective logs for example. The reasoning behind this is very simple, during a complete shutdown the system does final check-ups and stuff until the computer
shuts down.
Any writing operations done to the registry can lead to erratic behaviors. CmShutdownSystem call already invokes a final flushing of all the hives on the backing storage which is more than enough to ensure consistency of the last session configuration. So after that final flushing, mark HvShutdownComplete as TRUE indicating
that any eventual flushing or syncying (in the case where HvSyncHive gets called) request is outright ignored.
NtSetDefaultLocale and ExpSetCurrentUserUILanguage do not probe the given locale or language ID,
and as a result of that these functions would happily take any given argument. This is problematic
because overwriting NLS data (specifically the Default registry key value as its gets set by the
NtSetDefaultLocale syscall itself) with garbage stuff, rendering the system completely unbootable.
In addition to that, these functions do not check the captured language/locale ID against pre-determined
locales or languages pre-installed in the system. This basically means an ID of 1, for example, is still
valid because it is not bogus albeit there is no such a locale of an ID of 1. That value would get passed
to the Default value key and that renders the system unbootable as well.
CORE-18100
- Stay attached while deleting the VAD node
- Acquire the appropriate working set lock when deleting a VAD node
- Both are needed for locking correctness
- Acquire the appropriate working set lock when calling MmLocateMemoryAreaByAddress
- Do not access MemoryArea without holding the lock (otherwise it can be pulled away under our feet)
- Fix range check for paged pool
These faults are handled by ARM³ and we don't need to check for a memory area. They can be recursive faults (e.g. from MiDeleteSystemPageableVm), so we might be holding the WS lock already. Passing it straight to ARM³ allows to acquire the WS lock below to look up the memory area.
Addendum to commit b3c55b9e6 (PR #4399).
Passing &CapturedObjectName as pointer to be probed and captured would
fail if e.g. PreviousMode == UserMode, since that pointer is always in
kernel space. Instead, pass the original user-mode pointer.
Bug caught by Timo Kreuzer ;)
This is a hack, because the kernel mode path can incur a recursive page fault with the AddressCreationLock acquired, which would lead to a recursive acquisition, once we do proper locking in MmAccessFault.
To properly fix this the PDE must be made valid, similar to the user mode path, but that is not that simple...
They can be spammy. Also clarify these debug prints, because some people
think that "failed to grant access rights" means there's something wrong
in the core access check functions.
Temporarily add the local group to the system token so that Virtualbox
GA services can properly set up network drives for shared folders.
What happens is that a security descriptor has a DACL with only one ACE
that grants access to Local SID (presumably coming from Vbox?)
but the client token is that of the service which is a SYSTEM token.
Perhaps we are not impersonating the right user or whatever else.
This is only a temporary placebo, until a proper solution is found.
CORE-18250
Certain apps such as AIM installer passes an empty generic mapping (this can
be understood with their generic masks set to 0) and our code tries to map
the access right from an ACE with the mapping provided by AccessCheck.
This can lead to a bug where we would not be able to decode the generic right
from an ACE as we need a proper generic mapping in order to do so. A mask
right that is not decoded it cannot be used to mask out the remaining rights,
further resulting into a denied access right.
What Windows does instead is they are mapping the ACE's rights in another place,
presumably when setting security data to an object, and they are using the
generic mapping passed by the kernel.
What we can do for the time being is to temporarily grant access to the client,
but only if they are an administrator.
CORE-18576
During an open or create procedure of a registry key, the registry parser grabs
a key control block (KCB) from the parser object and uses its information to do the
necessary work in order to obtain a pointer to the newly created or opened registry key.
However, the registry parsers faces several issues. First, we don't do subkey cache cleaning
information against gathered KCBs so whenever we do a registry parse we end up with KCBs
that have cache inconsistencies. Moreover we don't do any locking of whatever KCB we
are grabing during a parse procedure.
=== PROPOSED CHANGES ===
* Implement CmpComputeHashValue and CmpLookInCache functions. With CmpComputeHashValue we can
compute the convkey hashes of each subkey in the path name of a key so we can lock them
with CmpBuildAndLockKcbArray. CmpLookInCache is a function that searches for the suitable
KCB in the cache. The factors that determine if a KCB is "suitable" are:
-- the currently found KCB in the hash list has the same levels as that of the
given KCB from the parse object;
-- The key names from the computed hash values match with the block name of
the KCB;
-- The currently found KCB is not deleted.
The KCB will be changed if the key path name points to a partial match name in
the cache. The KCB from the parse object will be used if we have a full match
of remaining levels.
* Add missing CMP_LOCK_HASHES_FOR_KCB flags on CmpCreateKeyControlBlock calls
that create KCBs during a parse procedure. Such lock has to be preserved until
we're done with the registry parsing.
* On CmpDoCreateChild, preserve the exclusive lock of the KCB when we are
enlisting the key body.
* On CmpDoCreate, make sure that the passed parent KCB is locked exclusively and
lock the hiver flusher as we don't want the flusher to kick in during a key
creation on the given hive. Cleanup the subkey info when we're creating a key
object. Also implement missing cleanup path codes. Furthermore, avoid key
object creation if the parent KCB is protected with a read-only switch.
* Soft rewrite the CmpDoOpen function, namely how we manage a direct open vs
create KCB on open scenario. When a KCB is found in cache avoid touching
the key node. If the symbolic link has been resolved (aka found) then lock
exclusively the symbolic KCB. Otherwise just give the cached KCB to the caller.
If it were for the caller to request a KCB creation, we must check the passed
KCB from the parser object is locked exclusively, unlike on the case above
the caller doesn't want to create a KCB because there's already one in the cache.
We don't want anybody to touch our KCB while we are still toying with it during
its birth. Furthermore, enlist the key body but mind the kind of lock it's been
used.
* On CmpCreateLinkNode, avoid creating a key object if the parent KCB is protected
with a read-only switch. In addition, add missing hive flusher locks for both
the target hive and its child. Cleanup the subkey information of the KCB when
creating a link node, this ensures our cached KCB data remains consistent.
* Do a direct open on CmpParseKey if no remaining subkey levels have been found
during hash computation and cache lookup, in this case the given KCB is the
block that points to the exact key. This happens when for example someone tried
to call RegOpenKeyExW but submitting NULL to the lpSubKey argument parameter.
CORE-10581
ROSTESTS-198
