On Thu Oct 19 14:27:02 2023 +0000, Hans Leidekker wrote:
> What should applications have used if /etc/machine-id wasn't readable?
> I think it's fine to derive the missing fields from machine-id.
should have embedded it inside **sd_id128_get_machine_app_specific** (removing the machine-id parameter)
you mean derive by keeping readable a field explicitely marked as non public !!!
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4108#note_49304
The PE build uses FlsAlloc(), which for our purposes makes no difference vs TlsAlloc(), and allows the use of a destruction callback.
--
v6: vkd3d: Replace the descriptor object cache with a thread-local implementation.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/384
On Thu Oct 19 13:35:46 2023 +0000, Francisco Casas wrote:
> I see. So the `probe` part may be deserving of a `todo(sm<4)`.
> I made patches for that on the second part of !418, but I think that for
> now it is okay to leave the requirement.
Oh no, you are right, compiling with the native compiler and running on Windows we get those broken results, so it is not a problem of the compiler itself.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/417#note_49297
On Thu Oct 19 09:51:46 2023 +0000, Nikolay Sivov wrote:
> It does compile, but results are broken. That's what I get on Windows:
> `shader_runner:683: Section [test], line 51: Test failed: Got
> {8.40779079e-045, 9.80908925e-045, -1.#QNAN000e+000, 4.20389539e-045},
> expected {6.00000000e+000, 7.00000000e+000, -1.00000000e+000,
> 3.00000000e+000} at (0, 0).`
> That happens because of the lack of itof conversion on SM3. So ints we
> set are returned as is, after ceil() is optimized away for integers.
I see. So the `probe` part may be deserving of a `todo(sm<4)`.
I made patches for that on the second part of !418, but I think that for now it is okay to leave the requirement.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/417#note_49293
because it's explicitly requested. man machine-id
> ```plaintext
> This ID uniquely identifies the host. It should be considered "confidential", and must not be exposed in untrusted environments, in particular on the network. If a stable unique identifier that is tied to the machine is needed for some application, the machine ID or any part of it must not be used directly. Instead the machine ID should be hashed with a cryptographic, keyed hash function, using a fixed, application-specific key. That way the ID will be properly unique, and derived in a constant way from the machine ID but there will be no way to retrieve the original machine ID from the application-specific one. The sd_id128_get_machine_app_specific(3) API provides an implementation of such an algorithm.
> ```
(looks like /etc/machine-id should never have been user readable, and this is about reducing the exposure)
for the second patch in the serie, the we need to craft missing info (because some DMI fields are only readble by root), do you also recommand to reuse directly machine-id? (it would be better to not tie the values to a given prefix, anticheat vendors will not like it), so the least worst choice is deriving from machine-id.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4108#note_49291