lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 23 Feb 2012 10:42:16 -0800
From:	Arun Sharma <>
To:	Balbir Singh <>
CC:	<>, <>,
	KAMEZAWA Hiroyuki <>,
Subject: Re: [PATCH] mm: Enable MAP_UNINITIALIZED for archs with mmu

Hi Balbir,

Thanks for reviewing. Would you change your position if I limit the 
scope of the patch to a cgroup with a single address space?

The moment the cgroup sees more than one address space (either due to 
tasks getting created or being added), this optimization would be turned 

More details below:

On 2/22/12 11:45 PM, Balbir Singh wrote:
> So the assumption is that only apps that have access to each others
> VMA's will run in this cgroup?

In a distributed computing environment, a user submits a job to the 
cluster job scheduler. The job might involve multiple related 
executables and might involve multiple address spaces. But they're 
performing one logical task, have a single resource limit enforced by a 

They don't have access to each other's VMAs, but if "accidentally" one 
of them comes across an uninitialized page with data from another task, 
it's not a violation of the security model.

> Sorry, I am not convinced we need to do this
> 1. I know that zeroing out memory is expensive, but building a
> potential loop hole is not a good idea
> 2. How do we ensure that tasks in a cgroup should be allowed to reuse
> memory uninitialized, how does the cgroup admin know what she is
> getting into?

I was thinking of addressing this via documentation (as in: don't use 
this if you don't know what you're doing!). But limiting the scope to a 
single address space cgroup seems cleaner to me.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists