linux-kernel - Re: [PATCH v2 6/6] Account certain kmem allocations to memcg

lists.openwall.net		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] [day] [month] [year] [list]

Message-ID: <20151119191229.GF3941@cmpxchg.org>
Date:	Thu, 19 Nov 2015 14:12:29 -0500
From:	Johannes Weiner <hannes@...xchg.org>
To:	Vladimir Davydov <vdavydov@...tuozzo.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Michal Hocko <mhocko@...nel.org>, Tejun Heo <tj@...nel.org>,
	Greg Thelen <gthelen@...gle.com>,
	Christoph Lameter <cl@...ux.com>,
	Pekka Enberg <penberg@...nel.org>,
	David Rientjes <rientjes@...gle.com>,
	Joonsoo Kim <iamjoonsoo.kim@....com>, linux-mm@...ck.org,
	cgroups@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 6/6] Account certain kmem allocations to memcg

On Tue, Nov 10, 2015 at 09:34:07PM +0300, Vladimir Davydov wrote:
> This patch marks those kmem allocations that are known to be easily
> triggered from userspace as __GFP_ACCOUNT/SLAB_ACCOUNT, which makes them
> accounted to memcg. For the list, see below:
> 
>  - threadinfo
>  - task_struct
>  - task_delay_info
>  - pid
>  - cred
>  - mm_struct
>  - vm_area_struct and vm_region (nommu)
>  - anon_vma and anon_vma_chain
>  - signal_struct
>  - sighand_struct
>  - fs_struct
>  - files_struct
>  - fdtable and fdtable->full_fds_bits
>  - dentry and external_name
>  - inode for all filesystems. This is the most tedious part, because
>    most filesystems overwrite the alloc_inode method.
> 
> The list is by far not complete, so feel free to add more objects.
> Nevertheless, it should be close to "account everything" approach and
> keep most workloads within bounds. Malevolent users will be able to
> breach the limit, but this was possible even with the former "account
> everything" approach (simply because it did not account everything in
> fact).
> 
> Signed-off-by: Vladimir Davydov <vdavydov@...tuozzo.com>

Thanks for doing that work, Vladimir. It looks reasonable to me.

We can update the list as we go along and testing reveals more things
that need to be considered. As far as malicious users go, I agree that
we can not make this bullet proof, and so we shouldn't aim for that.

Acked-by: Johannes Weiner <hannes@...xchg.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/