To be fair, at this point, the process should be dead and the Cookie should no longer be relevant, but from a security perspective, I would be warry about echo'ing back the expected checksum.
I understand the rationale behind, but I could think about some circumstances (forked process, VM snapshots, etc), where that information could potentially be reused to craft a correct header.
It obviously would require the attacker to get their hands on the logs first.

I like the idea of randomizing the regions' base!

Seems to be EXPECT_EQ(0, LastRequestSize); related. Potential fix would be 0U for both instances.

If you could please change InitRingBuffer & RingBufferSizeInBytes to abide to the LLVM coding standard (https://llvm.org/docs/CodingStandards.html#name-types-functions-variables-and-enumerators-properly)

High level question: was this tested with Fuchsia/Linux/Android?

Thanks! Missed one :)

Can we use the LLVM style for this change?
eg: no k* constants, casing for pos, fd etc.

Do we have rough numbers as to how this lowers the "randomness" of the pool of blocks to be chosen for various classes?

While this is true, making the Counts smaller can have structure alignement consequences.
You probably want to make sure that TransferBatch, FreeBatch, PreClass etc all look fine (size multiple of sizeof(uptr) etc). If not the case, you would have to pad.
Other things to keep in consideration: u32 vs u16 in getMaxCachedHint, TransferBatch::get and others (static_cast<u32> might be a giveaway of some integer size inconsitency).
If all works out, that might mean that the SizeClassConfig will have to be adapted to best fit the new sizes.

... and remove local debugging line.

Addressing Mitch's request.

Thank you!

In rG45138f788c9b3c4ac5d9ae4479841c411c15190e#1020320, @rupprecht wrote:

Are you looking at resolving this build failure? Or maybe @cryptoad is?

I apologize, I messed up the revert of my other CL and this got reverted by mistake!

In D108089#2947081, @hctim wrote:

Side note - it'd be nice at some point if we can LSC all the use-of-custom-types away, any reason to keep them?

Redoing this the way Vitaly suggested.

So this turned out to be a little more complicated for 32-b.
The 'z' format specifier expects a size_t which is defined
as a unsigned int on 32-b Linux platforms, while our
scudo::uptr are defined a unsigned long. So zu wasn't
an appropriate specifier on 32-b platforms for a uptr.

In D106502#2895464, @sivachandra wrote:

@cryptoad - This adds a build level dependency across projects. Do you see any problems which this arrangement? We will also start testing this arrangement via integration tests on the LLVM libc buildbot workers.

Using using instead of typedef on the newly added ones.

Adding more isAligned DCHECK as Vitaly suggested.

Add stdlib.h to the test for posix_memalign. My builds don't
complain but I assume something will eventually.

In D103119#2822008, @yroux wrote:

Hi,

this is due to a misaligned data access, in Thumb the code generated for unmapTestOnly
contains a Vector Store instruction vst1.64 {d16-d17}, [r0, :128] which needs a 16-bytes
alignement, but the adress of TSDs (which is in r0) is not.

In D103119#2807183, @yroux wrote:

Hi,

This change introduced a regression on ARMv7 Thumb bots which wasn't noticed due to other issues.

logs can be seen here: https://lab.llvm.org/buildbot/#/builders/26/builds/2251

The 3 tests fail with a bus error raised from tsd_shared.h line 49