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 98E47C6FA8B for ; Fri, 23 Sep 2022 14:02:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231796AbiIWOBi (ORCPT ); Fri, 23 Sep 2022 10:01:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57026 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231836AbiIWOBL (ORCPT ); Fri, 23 Sep 2022 10:01:11 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2E10F13A380 for ; Fri, 23 Sep 2022 07:01:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1663941669; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=xjBO7tA9U+8DAn/vreMh0HlzjoAqH166EctUNXQAP6U=; b=ZMatY6Gf216R4WG4Jcpc6ed1MPqW8Ftji+5YxpiqArJ26gMhhmkw+BV0xOkNX57ay/KHmH 07Fp7o1tvJXY0AbyzN3VrViOgYEaIkTRlAhCbkVsrtLWEJISm0N29P9WEF1tE64X9a9Zc0 1gbXupD+f8gH9v23TpdAjcqWoYAEwhc= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-30-UsC3BSuHOY6UBfzeRcNcSQ-1; Fri, 23 Sep 2022 10:01:06 -0400 X-MC-Unique: UsC3BSuHOY6UBfzeRcNcSQ-1 Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 387A72A2AD7B; Fri, 23 Sep 2022 14:01:05 +0000 (UTC) Received: from redhat.com (unknown [10.33.36.67]) by smtp.corp.redhat.com (Postfix) with ESMTPS id CA71D4B401E; Fri, 23 Sep 2022 14:00:57 +0000 (UTC) Date: Fri, 23 Sep 2022 15:00:55 +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: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/2.2.6 (2022-06-05) X-Scanned-By: MIMEDefang 3.1 on 10.11.54.9 Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Fri, Sep 23, 2022 at 10:46:21AM -0300, Jason Gunthorpe wrote: > On Fri, Sep 23, 2022 at 02:35:20PM +0100, Daniel P. Berrangé wrote: > > On Fri, Sep 23, 2022 at 10:29:41AM -0300, Jason Gunthorpe wrote: > > > On Fri, Sep 23, 2022 at 09:54:48AM +0100, Daniel P. Berrangé wrote: > > > > > > > Yes, we use cgroups extensively already. > > > > > > Ok, I will try to see about this > > > > > > Can you also tell me if the selinux/seccomp will prevent qemu from > > > opening more than one /dev/vfio/vfio ? I suppose the answer is no? > > > > I don't believe there's any restriction on the nubmer of open attempts, > > its just a case of allowed or denied globally for the VM. > > Ok > > For iommufd we plan to have qemu accept a single already opened FD of > /dev/iommu and so the selinux/etc would block all access to the > chardev. A selinux policy update would be needed to allow read()/write() for the inherited FD, whle keeping open() blocked > Can you tell me if the thing invoking qmeu that will open /dev/iommu > will have CAP_SYS_RESOURCE ? I assume yes if it is already touching > ulimits.. The privileged libvirtd runs with privs equiv to root, so all capabilities are present. The unprivileged libvirtd runs with same privs as your user account, so no capabilities. I vaguely recall there was some way to enable use of PCI passthrough for unpriv libvirtd, but needed a bunch of admin setup steps ahead of time. 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 :|