On 4/3/2025 2:06, Jacek Caban wrote:
On 3.03.2025 14:22, Alvin Wong wrote:
I think both the current approach of lacking load config and the
proposed solution are fragile. Instead of relying on unrelated
linker warnings, if such a warning is necessary, it should be
implemented properly, with a clear message that users can understand
without needing to dive into mingw-w64 specifics.
I’ve attached a possible solution on the LLD side. In its current
form, it would warn on recent CFGuard-enabled mingw-w64 due to the
missing @feat.00 flag, but it's just an example of a potential
approach.
Thanks for the suggestion. I think it is a nice idea to add. But in
practice, since the current loadcfg has been missing the `@feat.00`
flag we cannot rely on it in the short term. Besides, at least for
MSVC target, users can provide their own `_load_config_used` data
structure (which is rare, but does seem to happen occasionally) and
in that case we cannot use check its object file to determine
something about the runtime.
I guess you can say perform the check only in mingw mode, but in that
case maybe it would be better to check something directly from
mingw-w64 that already has the flag today, like gccmain.o in
libmingwex.a (for example)?
But it'll also need to consider the case of linking with `-nostdlib`.
MinGW targets may provide their own load config or even an entire CRT
(with -nostdlib). In such cases, it makes more sense to check the
actual file being used rather than tying it specifically to libmingwex.a.
My point is that if the `_load_config_used` symbol is not one from the
mingw-w64 runtime, then saying CFGuard is "not supported by the runtime
library" in the warning will be misleading.
Maybe we could use the entry point symbol instead of load config. This
wouldn't work with -noentry, but I don't think it needs to be fully
bulletproof, as long as it avoids false positives. The current
solution isn't entirely robust either; for example, one could use a
non-CF Guard mingwex build along with a custom _load_config_used.
Yes, it would be something nice to have.
In the end it should be reviewed by LLD maintainers, but as long as the
check is restricted to mingw mode, I think it will be fine to include.
By the way, I have wondered if there should be warnings for any object
files (not just the runtime) not built with CFGuard. In practice it will
probably be triggered very often, but maybe having it as a non-default
option would be useful for things like security auditing.
Best Regards,
Alvin
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
