The `target_madvise` function returns success for unknown advice values, on grounds that most advice values are just hints: https://gitlab.com/qemu-project/qemu/-/blob/master/linux-user/mmap.c?ref_type=heads#L1289 However, for an unknown advice value, it is not a priori known when the value is a hint. The current behavior has a number of consequences: * It doesn't match the Linux kernel, which returns -1 for unknown advice and is [documented to do so](https://man7.org/linux/man-pages/man2/madvise.2.html#:~:text=EINVAL%20advice%20is%20not%20a%20valid.) * If the kernel adds a new non-hint advice value, qemu-user will do the wrong thing. In the past this has caused problems with `MADV_WIPEONFORK` (https://gitlab.com/qemu-project/qemu/-/work_items/343) and `MADV_DONTNEED` (https://gitlab.com/qemu-project/qemu/-/work_items/326). * It impedes detecting versions of QEMU that mishandle non-hint advice values. It is important to BoringSSL to distinguish between an environment that doesn't support `MADV_WIPEONFORK` vs one that does. We use that to decide whether to draw entropy more often, as a more expensive countermeasure. As we mentioned when reporting https://gitlab.com/qemu-project/qemu/-/work_items/343, since older QEMUs silently return success, we probe with `madvise(-1)` to check if the environment is broken. https://gitlab.com/qemu-project/qemu/-/commit/4530deb1fe81152ae2384a56eb7edb5467f894fa fixed handling of `MADV_WIPEONFORK`, but not handling of unknown values. As a result, BoringSSL's probe still reads newer QEMUs as not supporting `MADV_WIPEONFORK`, since the return value is unreliable. That means code running under qemu-user does not get the performance benefits despite now supporting the hint. It would be better for QEMU to instead only ignore the advice values that it are known to be safe to ignore, and then return errors on unknown ones.