Received: by 10.192.165.148 with SMTP id m20csp3621694imm; Mon, 30 Apr 2018 03:36:29 -0700 (PDT) X-Google-Smtp-Source: AB8JxZrJsc9etDmdLhcUK+krZNMnwXPqUzabkr3pTcbEWg4ZDLpqFEeFsKy57BAomMaEs6RNhE0f X-Received: by 2002:a17:902:b788:: with SMTP id e8-v6mr12035809pls.263.1525084589574; Mon, 30 Apr 2018 03:36:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525084589; cv=none; d=google.com; s=arc-20160816; b=eJxbTxTw1ksetKG+titk5Mg7woxCMby7GiVfrTJjxn51rrXXDNaDmb4vA+oBmxhTtZ SbbpVinZG+k/dZ/wqHdJe7z4dk2Kjca1HtyO4lJKbuIICGVbjOzIBKiL3WXwVuXPP0OA 8bbA4ST1Lw91fA1LKGK+DX86jUhbiQEInqt7frI1GvnB8+ldPUtzswsv2twFQIpfoJTP N35V2IA4+XE92OLkXPyMgCDdFZTYlWFL1RbLriaHb+qrmmUYEm9lKIL014Gludxx2RcP ggEJdtg3q6H5uz6lJL593cHi/H5n7XGV9CqUefT101Tnc2feshQcv0WkxHvddd75U4BP iWJg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=4FY5RFwa9jjlclLxXqtuj7s8UurexZTEl9jCK8niHUg=; b=Phc5OloW0MSq2Ti+tAf5KTeH7pzZhpcHbCV1w5Y84/XI3OUQsH/6WnHUVcNsXXiifN wAgxWM/OqTGT3E/oNI2QKMd+0YtTYubMMLpCtcJNeLampsXipivxGV9V3YZo8xm2cPfO GLvznOUimyjO2Usj7DHwgmpCwp0TRV+SCyhH1cGlaED+m2RCWC/UUoa0MF6RjprSCokC KRH7014MEiwegHXLN6/rXwBHhinbzeGM+buGMpORu88ORMwwKpU42l/3uUF2s88z8awD rilgY0VYVDGGUGReTR0tFWgX1/clXrQ0a8mj0Yqq6v1V19frssfQZ5xd9lwRrCb4MgDM jqxg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=AXTYr7hi; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r9-v6si7227050plo.442.2018.04.30.03.36.15; Mon, 30 Apr 2018 03:36:29 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=AXTYr7hi; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753883AbeD3Kft (ORCPT + 99 others); Mon, 30 Apr 2018 06:35:49 -0400 Received: from mail-qt0-f179.google.com ([209.85.216.179]:38601 "EHLO mail-qt0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753744AbeD3Kfq (ORCPT ); Mon, 30 Apr 2018 06:35:46 -0400 Received: by mail-qt0-f179.google.com with SMTP id z23-v6so10289511qti.5 for ; Mon, 30 Apr 2018 03:35:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4FY5RFwa9jjlclLxXqtuj7s8UurexZTEl9jCK8niHUg=; b=AXTYr7hiRQ8/ZGIYy45lyxdmPCt9PrvlkpgFXyMxzFLWy97dZgrN0T5GhK0oDlJ5lM ySEqfc0kaJEboy87Fk78TsSaBzxHPySM4t/fqH+chGCotMi1B8D8oFx8SufP5VBjYP9I 2mFS6Km4RxgVKQv2PqNDinaxzbl/V5Q4/pmjyRPiOM+ZG9TUQ7VhqoefSjg9pvYxw1Bg V4vcWu/9QiISn6zIfQ7dC8SNpPJTBMXMKeN49PHyFloYElh/gntQqrKcRq8OJYWc36/J Zo6lKNKgwwqbDwqBrcI0XrfzB7FqrfrEb+d6FXK79ZSxnsdfsQtVhJxu7eLfcl4SGnsQ 5Cug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4FY5RFwa9jjlclLxXqtuj7s8UurexZTEl9jCK8niHUg=; b=hByTyO1HxyUJOozX5juyT6c5phLdiJnqQQ97ZCehxOCr8Z28tWklDzYWlp73wsDu0D P3CHQHgiElAWFTroBoYcDRg/mRAZpSQjTzl+KCarpJm7hSGqOHcFurv9uYkKemN1nQsJ kaurFFZeGexqqWoe4072cyDhYugWHTeijAXDu+v88BP21HXmYDOG857KUGqCoIdlpaqG RTvh3N4xzX5AbPIxusvYdHszsiszezMKfTrgMUJbh0OmXcZzONsseLmmryRWZ18UL6oH bhH06J7PUEVQButmcho1Z1PEzdZHz6wNTwLyUR3WCdz9Cna6Cz7IQ5NP+tUwyk/A4Tzc zZkQ== X-Gm-Message-State: ALQs6tCq+UKQBge2NO/YRQFpS5xC6xpuxsa1szfQXubpKjJk1xO9Fz0G zGNHbImrk+o97R8DfhMJtkTSnLgu8n19gPdU/c4j+g== X-Received: by 2002:aed:3445:: with SMTP id w63-v6mr11542352qtd.192.1525084545840; Mon, 30 Apr 2018 03:35:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.71.5 with HTTP; Mon, 30 Apr 2018 03:35:25 -0700 (PDT) In-Reply-To: <12218300.6oQjICIiUq@ferry-quad> References: <9023506.UBh6vynRGa@delfion> <1524470676.5451.1.camel@gmx.de> <20180425155459.5a4e40e0@alans-desktop> <12218300.6oQjICIiUq@ferry-quad> From: Miguel Ojeda Date: Mon, 30 Apr 2018 12:35:25 +0200 Message-ID: Subject: Re: DOS by unprivileged user To: Ferry Toth Cc: Alan Cox , Mike Galbraith , linux-kernel Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 30, 2018 at 12:00 PM, Ferry Toth wrote: > Op woensdag 25 april 2018 16:54:59 CEST schreef Alan Cox: >> > > 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. >> >> It belongs in both. >> >> Classical Unix systems never had this problem because they respond to >> thrashing by ensuring that all processes consumed CPU and made some >> progress. Linux handles it by thrashing itself to dealth while BSD always >> handled it by moving from paging more towards swapping and behaving like >> a swap bound batch machine. >> >> Linux thrashes itself to death, the classic BSD algorithn instead throws >> fairness out of the window under extreme load to prevent it. It might take >> a few seconds but at least you will get your prompt back. >> >> Alan >> > I haven t tried BSD. > > But when I was young I allocated 10MB on a HP9000 (UX) with 1MB of RAM. People wanted to launch me out of the window (18th floor). > > I did not want to say Unix was better, only with so much emphasis on security I' m surprised how easy it is for a regular user to bring linux to on it s knees. While it is true that things can be improved/tweaked for typical desktop/single user usage; this isn't really a security issue. For shared systems, there are a few ways to soft/hard limit resources: nice, *limit, cgroups, systemd limits, containers/VMs... Cheers, Miguel