From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 89D79C54EE9 for ; Thu, 22 Sep 2022 11:21:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230397AbiIVLVD (ORCPT ); Thu, 22 Sep 2022 07:21:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40978 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229991AbiIVLVC (ORCPT ); Thu, 22 Sep 2022 07:21:02 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 36491DE0FD for ; Thu, 22 Sep 2022 04:21:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1663845660; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references; bh=VuYqmWHx8E1Kx7C1xkE5SwjBorzdn+d+oVW6/OMVJJw=; b=c2ciACADM36jRrr1SInY+ZY5NCOHru8XZI1LZIkUFP+4IoBlPVL8WP9lyDNS3Aq9tZciCM VjURlsbtLj4qsWZYrpuMXbnWnl+L4fMFKSyAfevmD/R++YHcqrlvppkW+uPHG5Ukx3o/EA jGnHe8rvPfDf2rxcq91IRwhmt44X2mM= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-331-zeKxygzaOwWJIVJYYcOBYg-1; Thu, 22 Sep 2022 07:20:57 -0400 X-MC-Unique: zeKxygzaOwWJIVJYYcOBYg-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 42D0C85A59D; Thu, 22 Sep 2022 11:20:56 +0000 (UTC) Received: from redhat.com (unknown [10.33.36.120]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 629EE40C83DD; Thu, 22 Sep 2022 11:20:52 +0000 (UTC) Date: Thu, 22 Sep 2022 12:20:50 +0100 From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= To: Jason Gunthorpe Cc: Alex Williamson , Eric Auger , "Tian, Kevin" , "Rodel, Jorg" , Lu Baolu , Chaitanya Kulkarni , Cornelia Huck , Daniel Jordan , David Gibson , Eric Farman , "iommu@lists.linux.dev" , Jason Wang , Jean-Philippe Brucker , "Martins, Joao" , "kvm@vger.kernel.org" , Matthew Rosato , "Michael S. Tsirkin" , Nicolin Chen , Niklas Schnelle , Shameerali Kolothum Thodi , "Liu, Yi L" , Keqian Zhu , Steve Sistare , "libvir-list@redhat.com" , Laine Stump Subject: Re: [PATCH RFC v2 00/13] IOMMUFD Generic interface Message-ID: Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= References: <0-v2-f9436d0bde78+4bb-iommufd_jgg@nvidia.com> <20220921120649.5d2ff778.alex.williamson@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/2.2.6 (2022-06-05) X-Scanned-By: MIMEDefang 3.1 on 10.11.54.1 Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Wed, Sep 21, 2022 at 03:44:24PM -0300, Jason Gunthorpe wrote: > On Wed, Sep 21, 2022 at 12:06:49PM -0600, Alex Williamson wrote: > > The issue is where we account these pinned pages, where accounting is > > necessary such that a user cannot lock an arbitrary number of pages > > into RAM to generate a DoS attack. > > It is worth pointing out that preventing a DOS attack doesn't actually > work because a *task* limit is trivially bypassed by just spawning > more tasks. So, as a security feature, this is already very > questionable. The malicious party on host VM hosts is generally the QEMU process. QEMU is normally prevented from spawning more tasks, both by SELinux controls and be the seccomp sandbox blocking clone() (except for thread creation). We need to constrain what any individual QEMU can do to the host, and the per-task mem locking limits can do that. The mgmt app is what spawns more tasks (QEMU instances) and they are generally a trusted party on the host, or they are already constrained in other ways such as cgroups or namespaces. The mgmt apps would be expected to not intentionally overcommit the host with VMs needing too much cummulative locked RAM. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|