This MR introduces support for [thread safety annotations,](https://clang.llvm.org/docs/ThreadSafetyAnalysis.html#conditi… currently supported by Clang. The feature is similar to `__WINE_MALLOC` attributes, allowing functions, data members and global variables to be optionally annotated with synchronization details.
As a proof of concept, I have successfully annotated `dlls/ntdll` code, and it should build without any warnings.
Because the feature was designed as a C++ extension first, a bit of stubbing is required to annotate struct fields about what lock they are guarded by. The macros `WINE_DECLARE_LOCK_FIELD_STUB` and `WINE_DEFINE_LOCK_FIELD_STUB` take care of that. For instance, in `dlls/ntdll/threadpool.c`:
```c
WINE_DECLARE_LOCK_FIELD_STUB(threadpool_group, CRITICAL_SECTION, cs);
struct threadpool_group
{
LONG refcount;
BOOL shutdown;
CRITICAL_SECTION cs;
/* list of group members, locked via .cs */
struct list members __WINE_FIELD_GUARDED_BY(threadpool_group, cs);
};
WINE_DEFINE_LOCK_FIELD_STUB(threadpool_group, CRITICAL_SECTION, cs);
```
Clang will therefore warn if `members` is accessed without holding `cs`.
Note that the analyzer does not support conditional locking. For that reason, functions that hold and release a lock conditionally have been marked with `__WINE_NO_THREAD_SAFETY_ANALYSIS` to pre-empt false positives from Clang.
--
v2: ntdll: Add thread safety annotations.
configure: Enable -Wthread-safety-analysis, -Wthread-safety-attributes warnings.
include/winternl.h: Add thread safety annotations to several NT synchronization primitives.
include/winnt.h: Add macros for thread safety annotations.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6623
This MR introduces support for [thread safety annotations,](https://clang.llvm.org/docs/ThreadSafetyAnalysis.html#conditi… currently supported by Clang. The feature is similar to `__WINE_MALLOC` attributes, allowing functions, data members and global variables to be optionally annotated with synchronization details.
As a proof of concept, I have successfully annotated `dlls/ntdll` code, and it should build without any warnings.
Because the feature was designed as a C++ extension first, a bit of stubbing is required to annotate struct fields about what lock they are guarded by. The macros `WINE_DECLARE_LOCK_FIELD_STUB` and `WINE_DEFINE_LOCK_FIELD_STUB` take care of that. For instance, in `dlls/ntdll/threadpool.c`:
```c
WINE_DECLARE_LOCK_FIELD_STUB(threadpool_group, CRITICAL_SECTION, cs);
struct threadpool_group
{
LONG refcount;
BOOL shutdown;
CRITICAL_SECTION cs;
/* list of group members, locked via .cs */
struct list members __WINE_FIELD_GUARDED_BY(threadpool_group, cs);
};
WINE_DEFINE_LOCK_FIELD_STUB(threadpool_group, CRITICAL_SECTION, cs);
```
Clang will therefore warn if `members` is accessed without holding `cs`.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6623
This MR is the first of at least three MRs adding support for the Bluetooth stack API in Wine:
1. The winebth.sys driver, which talks to BlueZ and implements several key IOCTLs for communicating with Bluetooth devices and radios.
2. A bthserv service, which is responsible for keeping track of the authentication agent, and relaying authentication requests and responses to and from the driver.
3. Userspace APIs (bluetoothapis.dll, bthprops.cpl, Windows.Devices.Bluetooth, etc).
winebth.sys is split into two "sub" drivers:
`winebth.sys`: The main entrypoint, loaded by winedevice. It listens for changes to Bluetooth devices and radios and authentication events on BlueZ, passing them on the bthenum. It also handles most IOCTL operations on Bluetooth radio PDOs.
`bthenum`: Responsible for creating nodes for discovered Bluetooth devices and associated services. It also tries to validate any IOCTLs relating to bluetooth devices before passing them to winebth.sys.
The unix code is split between dbus.c, unixlib.c and winebluetooth.c, where winebluetooth is a simple wrapper around unixlib for the sake of organization.
--
v3: winebth.sys: Implement IOCTL_WINEBTH_SEND_AUTH_RESPONSE.
winebth.sys: Add support for receiving authentication requests/events.
winebth.sys: Add support for BLUETOOTH_RADIO_IN_RANGE events (WM_DEVICECHANGE).
winebth.sys: Implement IOCTL commands IOCTL_WINEBTH_RADIO_SET_FLAG and IOCTL_WINEBTH_RADIO_UNSET_FLAG.
winebth.sys: Implement IOCTL commands IOCTL_WINEBTH_RADIO_START_DISCOVERY and IOCTL_WINEBTH_RADIO_STOP_DISCOVERY.
winebth.sys: Implement IOCTL_BTH_GET_LOCAL_INFO for radio devices.
winebth.sys: Update radio PDO properties when BlueZ sends us a PropertiesChanged for an adapter.
winebth.sys: Create PDOs for Bluetooth services discovered on remote devices.
winebth.sys: Create PDOs for newly discovered remote Bluetooth devices.
winebth.sys: Create PDOs for newly discovered Bluetooth radios.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6621
This MR should be the first of at least three MRs, adding support for the Bluetooth stack API in Wine:
1. The winebth.sys driver, which talks to BlueZ and implements several key IOCTLs for communicating with Bluetooth devices and radios.
2. A bthserv service, which is responsible for keeping track of the authentication agent, and relaying authentication requests and responses to and from the driver.
3. Userspace APIs (bluetoothapis.dll, bthprops.cpl, Windows.Devices.Bluetooth, etc).
winebth.sys is split into two drivers:
winebth.sys: The main entrypoint, loaded by winedevice. It listens for changes to Bluetooth devices and radios and authentication events on BlueZ, passing them on the bthenum. It also handles most IOCTL operations on Bluetooth radio PDOs.
bthenum: Responsible for creating nodes for discovered Bluetooth devices and associated services. It also tries to validate any IOCTLs relating to bluetooth devices before passing them to winebth.sys.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6621
Testing on Windows shows that the owner of GetDesktopWindow() always has a default admin token with `TokenElevationTypeDefault`, no matter the token of the process/thread that is responsible for creating it.
We've had issues in this area in the past - 99e2fad1 was a case where it was important that explorer not inherit the token of the *process* spawning it, but instead the token of the *thread*. This patch keeps that app working, since now explorer will get a default token regardless.
In addition to the privilege issues from 99e2fad1, it is a relatively common pattern to duplicate the token of the owner of GetDesktopWindow to acquire a default token.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6602