Peter Maydell <peter.mayd...@linaro.org> writes:
> If you build QEMU with the clang sanitizer enabled, you can see it > fire when running the arm-cpu-features test: > > $ QTEST_QEMU_BINARY=./build/arm-clang/qemu-system-aarch64 > ./build/arm-clang/tests/qtest/arm-cpu-features > [...] > ../../target/arm/cpu64.c:125:19: runtime error: shift exponent 64 is too > large for 64-bit type 'unsigned long long' > [...] > > This happens because the user can specify some incorrect SVE > properties that result in our calculating a max_vq of 0. We catch > this and error out, but before we do that we calculate > > vq_mask = MAKE_64BIT_MASK(0, max_vq);$ > > and the MAKE_64BIT_MASK() call is only valid for lengths that are > greater than zero, so we hit the undefined behaviour. Hmm that does make me worry we could have more land mines waiting to be found. Would converting MAKE_64BIT_MASK into an inline function and asserting be a better solution? > > Change the logic so that if max_vq is 0 we specifically set vq_mask > to 0 without going via MAKE_64BIT_MASK(). This lets us drop the > max_vq check from the error-exit logic, because if max_vq is 0 then > vq_map must now be 0. > > The UB only happens in the case where the user passed us an incorrect > set of SVE properties, so it's not a big problem in practice. > > Signed-off-by: Peter Maydell <peter.mayd...@linaro.org> Reviewed-by: Alex Bennée <alex.ben...@linaro.org> -- Alex Bennée Virtualisation Tech Lead @ Linaro
