From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754170AbeDTIqP (ORCPT ); Fri, 20 Apr 2018 04:46:15 -0400 Received: from smtp.radex.nl ([178.250.146.7]:47507 "EHLO radex-web.radex.nl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753918AbeDTIqO (ORCPT ); Fri, 20 Apr 2018 04:46:14 -0400 From: Ferry Toth To: Mike Galbraith Cc: lkml Subject: Re: DOS by unprivileged user Date: Fri, 20 Apr 2018 10:39:21 +0200 Message-ID: <1911073.n8LaRrY1S6@ferry-quad> In-Reply-To: <1524199618.5757.3.camel@gmx.de> References: <9023506.UBh6vynRGa@delfion> <1524199618.5757.3.camel@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id w3K8kLp4005943 Op vrijdag 20 april 2018 06:46:58 CEST schreef Mike Galbraith: > On Thu, 2018-04-19 at 21:13 +0200, Ferry Toth wrote: > > It appears any ordinary user can easily create a DOS on linux. > > > > One sure way to reproduce this is to open gitk on the linux kernel repo > > (SIC) on a machine with 8GB RAM 16 GB swap on a HDD with btrfs and quad core > > + hyperthreading. But I will be easy enough to get the same effect with more > > RAM, other fs etc. > > > > In this case gitk allocates more and more memory (until my system freezes > > 6.5GB of 7.5GB avaiable), the system starts swapping or writing to tmp files > > (can't investigate as there is no time until it freezes) and the io wait > > goes to 100% on all cores. At this point it is impossible to login from > > remote and local keyboard and mouse are frozen. Hard reset is the only way > > out at this point. > > datapoint: my i4790/ext4 box running master.yesterday booted mem=8G > became highly unpleasant to use, but I retained control, and the all > cores going to 100% thing did not happen at any time. > > I didn't try constraining on the gitk user, just turned it loose a few > times to see if it managed to render box effectively dead. It failed > to kill my box, but (expectedly) did make it suck rocks. > > -Mike > Yes, might be less dramatic with ext4 than with btrfs (COW icw fsync on hdd's destroys performance of things like virtualbox, databases, dpkg). Nevertheless I feel one process should not be allowed to harm other processes by denying them resources. Even if when btrfs makes it easy abuse I think the scheduler should have throttled gitk.