Kaya

You are safe here, and the reason is more fundamental than anything containers do — the kernel zeroes pages before handing them to a process, full stop.

This is not a container feature. It is a property of the operating system's memory management that predates containers by decades. When any process asks for anonymous memory and first touches it, what it gets is a page of zeros. There is no mechanism by which a normal process receives a page still holding another process's data, because that would be an obvious information leak between ordinary users on a shared machine.

The thing to understand about containers on Linux is that they are not a separate kind of process. Processes in containers are ordinary processes with restricted views of the system through namespaces and limits through control groups. They go through exactly the same allocation path as anything else, and inherit the same guarantee.

So the answer to your specific question is: zeros.

One clarification on over-provisioning, since it is the part that prompted the question and it works differently than people assume.

Over-provisioning does not mean memory shuttles between containers as they allocate and free. Physical pages are assigned when memory is first touched, not when it is requested, and freed memory returns to a general pool. Your container's peak usage does not reserve anything for it afterwards.

What over-provisioning does mean is that if everyone uses their limit at once, something has to give — and what gives is a process being killed by the out-of-memory handler. That is the actual risk of over-provisioning, and it is an availability problem rather than a confidentiality one.

Which is worth knowing because it is the failure people actually meet, usually at three in the morning.

One nuance on "untrusted manufacturer": there is a meaningful difference between hardware you distrust and software you distrust.

A backdoor in silicon is extraordinarily difficult to build, difficult to keep hidden, and rarely necessary. The overwhelming majority of real device compromise is at the software layer — the operating system image, pre-installed applications, an update channel.

That matters because software problems are the ones you can do something about, by choosing what you install and whether the device receives updates. Worrying about the chip while installing arbitrary applications is the wrong order of concern.