[PATCH 0/7] RFC Memory tagging support

Szabolcs Nagy szabolcs.nagy@arm.com
Tue Jun 23 13:22:15 GMT 2020


The 06/15/2020 15:40, Richard Earnshaw wrote:
> Testing
> =======
> 
> I've run all the malloc tests.  While not all of them pass at present,
> I have examined all the failing tests and I'm confident that none of the
> failures represent real bugs in the code; but I have not yet decided how
> best to address these failures.  The failures fall into three categories
> 
> 1) Tests that expect a particular failure mode on double-free operations.
> I've added a quick tag-checking access in the free entry path that
> essentially asserts that the tag colour of a free'd block of memory
> matches the colour of the pointer - this leads to the kernel delivering
> a different signal that the test code does not expect.
> 
> 2) Tests that assume that malloc_usable_size will return a specific
> amount of free space.  The assumptions are not correct, because the
> tag colouring boundaries needed for MTE means that the 8 bytes in the
> block containing the back pointer can no-longer be used by users when
> we have MTE (they have a different colour that belongs to the malloc
> data structures).
> 
> 3) Tests that construct a fake internal malloc data structure and then
> try to perform operations on them.  I haven't looked at these in too
> much detail, but the first issue is that the fake header is only
> 8-byte aligned and for MTE to work it requires a 16-byte aligned
> structure (the tag read/write operations require the address be
> granule aligned, and the real glibc data structure has this property).

now i run the glibc tests with the latest linux patches,
the new failures are

FAIL: malloc/tst-malloc-backtrace
FAIL: malloc/tst-malloc-usable
FAIL: malloc/tst-malloc-usable-static
FAIL: malloc/tst-malloc-usable-static-tunables
FAIL: malloc/tst-malloc-usable-tunables
FAIL: malloc/tst-mallocstate
FAIL: malloc/tst-safe-linking
FAIL: malloc/tst-tcfree1
FAIL: malloc/tst-tcfree2
FAIL: malloc/tst-tcfree3
FAIL: nptl/tst-stack3
FAIL: nptl/tst-stack3-mem
FAIL: posix/tst-mmap

all malloc failures are use after free or poking
at malloc internals, except malloc/tst-malloc-usable,
which now can return smaller amount than the
original allocation size (with MALLOC_CHECK_=3).

posix/tst-mmap uses mmap on malloced memory and mmap
fails with ENOMEM because the tagged-address syscall
abi rejects tagged address in mmap, the test expects
EINVAL for not page aligned address, in strace i see
[pid  3505] mmap(0xf00fffff7d544a1, 1000, PROT_READ, MAP_SHARED|MAP_FIXED, 3, 0x1000) = -1 ENOMEM (Cannot allocate memory)
[pid  3505] mmap(0xf00fffff7d544a1, 1000, PROT_READ, MAP_PRIVATE|MAP_FIXED, 3, 0x1000) = -1 ENOMEM (Cannot allocate memory)
...
the output is
wrong error value for mapping at address with mod pagesize != 0: %m (should be EINVAL)
wrong error value for mapping at address with mod pagesize != 0: %m (should be EINVAL)
wrong error value for mapping at address with mod pagesize != 0: %m (should be EINVAL)
wrong error value for mapping at address with mod pagesize != 0: %m (should be EINVAL)

nptl/tst-stack3 and nptl/tst-stack3-mem are real
issues: glibc calls madvise MADV_DONTNEED on
stack on thread exit, even if it was user allocated
with malloc, the effect is that tags on the memory
may get zeroed, so when the user actually tries
to free the memory the integrity tag check crashes.
(i think this should be fixed by not doing madvise
on user allocated thread stacks, and user code is
not allowed doing madvise on malloced memory either,
but i assume that's rare)


More information about the Libc-alpha mailing list