In 'SUPR3InitEx' (SUPLib.cpp) a 'SUPQUERYFUNCS' structure is allocated
with
! (PSUPQUERYFUNCS)RTMemAllocZ(SUP_IOCTL_QUERY_FUNCS_SIZE(CookieReq.u.Out.cFunctions));
where 'CookieReq.u.Out.cFunctions' is 0. To determine the size of the
allocation
! #define SUP_IOCTL_QUERY_FUNCS_SIZE(cFuncs) \
! RT_UOFFSETOF_DYN(SUPQUERYFUNCS, u.Out.aFunctions[(cFuncs)])
is used with cFuncs = 0 (SUPDrvIOC.h) leading to an allocation up to the
arrow below
! typedef struct SUPQUERYFUNCS
! {
! /** The header. */
! SUPREQHDR Hdr;
! union
! {
! struct
! {
! /** Number of functions returned. */
! uint32_t cFunctions;
! /** Array of functions. */
==> end of allocation
! SUPFUNC aFunctions[1];
! } Out;
! } u;
==> sizeof(SUPQUERYFUNCS)
! } SUPQUERYFUNCS, *PSUPQUERYFUNCS;
In sup.cc (Genode) 'ioctl(SUPQUERYFUNCS &request)' will lead to
'with_out_ioctl'
! auto &out = request.u.Out;
where auto is 'SUPQUERYFUNCS' and finally
! out = { };
will zero out 'SUPQUERYFUNCS' up to the second arrow above. Because
'RTMemAllocZ' will call 'calloc' to allocate the memory 'out = { };'
will corrupt the slab block after the allocation. Therefore, it is
reasonable to allocate at least 'sizeof(SUPQUERYFUNCS)'.
Note there might be other 'ioctl' cases like this. A better way might be
to use 'SUPQUERYFUNCS.Hdr.cbOut' to determine the 'out' size.
fixes#4675
In case the meta data (or more) got zeroed upon 'free', print error
message. The offset in the meta data can never be zero. This does not
help on other memory corruptions, but at least gives a hint in the too
much zeroed out case.
issue #4675
GPU device access is hard to achieve in run scripts and even harder to
implement generic.
Use the "Modularize Sculpt OS image creation"
(commit b723b11b30)
approach instead.
issue #4900
The XHCI model reserves 0x4000 of IO memory but uses only 0x530.
Implement read (0) and write (nop) for these regions as real hardware
does.
fixes#4902
Triggered by the toolchain update to GCC 12 certain pragmas lead to
a build error as those are now unknown. As quick-fix add '-gnatwG',
which suppresses warnings on unrecognized pragmas.
Issue #4880.
When a GPU session is destroyed, remove vgpu of session from scheduling
and as possible active vgpu. Otherwise, page faults might occur in case
already destroyed vgpu object is referenced during interrupt handling.
fixes#4881
Apparently we need to save the floating point arguments when entering
the linker in case "-fno-tree-vectorize" is at work. Otherwise this
registers get corrupted during jump slot relocation.
Fixes#4879
