linux-kernel - Re: DOS by unprivileged user

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-next>] [day] [month] [year] [list]

Date:   Mon, 23 Apr 2018 10:04:36 +0200
From:   Mike Galbraith <efault@....de>
To:     Ferry Toth <ftoth@...fort.nl>
Cc:     linux-kernel@...r.kernel.org
Subject: Re: DOS by unprivileged user

On Sun, 2018-04-22 at 21:37 +0200, Ferry Toth wrote:
> > Yes your memory hog scenario thoroughly wrecks the user experience, but
> > the process scheduler in not the source of that wreckage, it's a memory
> > management issue.  With no constraints in place, anybody can just keep
> > on allocating until the entire system starts grinding itself to dust.
> > 
> > 	-Mike
>  
> That is exactly the issue I think. It is not just a user experience,
> they is no distinction between crashing the kernel and grinding it to
> dust. The effect we have is: any user on a multi user system can
> crash the system.
>  
> Memory management / constraints can't solve the problem either: it
> might be intentional to alloc such amounts of memory.

Constraints definitely can solve this particular problem instance. 
Plain old ulimit can stop the memory hog (wish) dead in its tracks, or
you can use memory cgroup controller to constrain it in a more friendly
manner.  I started gitk in a 4G constrained cgroup, which redirected
its greedy fingers to the swap bin for the remainder of its needs.

But yes, there is currently no wonderful one size fits all fully
automatic solution to running low on memory that doesn't involve
running to the store.

> I think memory allocation and io waits can't be decoupled from
> scheduling as they are now.

The scheduler is not decoupled from either, it is intimately involved
in both.  However, none of the decision making smarts for either reside
in the scheduler, nor should they.

	-Mike