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 X-Spam-Level: X-Spam-Status: No, score=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6A9FAC432BE for ; Sun, 29 Aug 2021 15:28:02 +0000 (UTC) Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 15E3A606A5 for ; Sun, 29 Aug 2021 15:28:01 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 15E3A606A5 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.linux-foundation.org Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id BECE74014B; Sun, 29 Aug 2021 15:28:01 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fCcb9jxTCnj3; Sun, 29 Aug 2021 15:27:57 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [140.211.9.56]) by smtp2.osuosl.org (Postfix) with ESMTPS id 4022E400AE; Sun, 29 Aug 2021 15:27:57 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id 1FEB8C001A; Sun, 29 Aug 2021 15:27:57 +0000 (UTC) Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 6667DC000E for ; Sun, 29 Aug 2021 15:27:55 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 5BE4340472 for ; Sun, 29 Aug 2021 15:27:55 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Authentication-Results: smtp4.osuosl.org (amavisd-new); dkim=pass (1024-bit key) header.d=redhat.com Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63DgdhI3awlT for ; Sun, 29 Aug 2021 15:27:54 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by smtp4.osuosl.org (Postfix) with ESMTPS id 2F6534046F for ; Sun, 29 Aug 2021 15:27:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1630250872; h=from:from: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=/S0QZCFqA24VJgqlctj6OrB5o3BOYhqGUcLEBNlCi1I=; b=FKL8Pvo9Glnqq4GAz9QH0B4HpMFI3HnYnv9GJMD/GGlnPsCexTaTbr7o1ztXbdqubzFoar xQ/rVWpDmZ/RDz+tyB74icqr77dYQxxhEs+DimGIpCVYiYzEEcVpbew0ZZtoxETNYlsNpj WGBD2cJjg8hEh5YRwMA0IWuYRpniZX4= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-161-V_0x7feCMFalnLZTPdyfXQ-1; Sun, 29 Aug 2021 11:27:49 -0400 X-MC-Unique: V_0x7feCMFalnLZTPdyfXQ-1 Received: by mail-wm1-f72.google.com with SMTP id h1-20020a05600c350100b002e751bf6733so3540466wmq.8 for ; Sun, 29 Aug 2021 08:27:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=/S0QZCFqA24VJgqlctj6OrB5o3BOYhqGUcLEBNlCi1I=; b=DgJ8/2Nr3OBC3hcyj8psEcq89UFsMuQmYGM3Kx7rhvFfZi9Oz9kbSIkST/qRv/2nnm dxgnPsSM87t271F1DocUMmz2DMRYl02e1mhDRUGfBTFSymZq8zDdK4lX+cPp1nE9zZBe WLuj3SlEdoZ+J2DDyos7b3Wy6ixHIUjySQlppduCFUnSYlF4qxPVLULqP3jgEH14eUjn 9mOnhcaUxqEew35I8oER9iQKZnXAkC05hc07thLScVCOhXouIxfxn2T4PllYsl+XAWvB M31ADCivJLGkBYB5bi1Cwp/UUblnAu03jCzyAsr80yHynle35GL8IcsgO4larmyE+gMJ nF1w== X-Gm-Message-State: AOAM530Kk4s18dFxqpwfOZl+SRfP8c1CooKOP/CuOpg3ECcNHQFSe6qC DDI3OQqOVcDsTvkBjucC6ykgHgcoAZ2BL2V3rhINZfUe3SzEjNzEo1PE+4whADwrH7j/T4aF1wJ mil9Cq+7H96217f2Teg3ihn4EGzOT2ttDFDnOg6O23A== X-Received: by 2002:a5d:6cc9:: with SMTP id c9mr9292548wrc.158.1630250868416; Sun, 29 Aug 2021 08:27:48 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwFpypfJ90QjoywS7jnahpw22uN0JXnwctorbzewr/oyY6u13VvTyKXFX7etQ/daiEVk+VHUA== X-Received: by 2002:a5d:6cc9:: with SMTP id c9mr9292527wrc.158.1630250868242; Sun, 29 Aug 2021 08:27:48 -0700 (PDT) Received: from redhat.com ([2.55.137.4]) by smtp.gmail.com with ESMTPSA id s1sm6762197wrs.53.2021.08.29.08.27.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 29 Aug 2021 08:27:47 -0700 (PDT) Date: Sun, 29 Aug 2021 11:27:42 -0400 From: "Michael S. Tsirkin" To: Andi Kleen Subject: Re: [PATCH v4 11/15] pci: Add pci_iomap_shared{,_range} Message-ID: <20210829112105-mutt-send-email-mst@kernel.org> References: <20210805005218.2912076-1-sathyanarayanan.kuppuswamy@linux.intel.com> <20210805005218.2912076-12-sathyanarayanan.kuppuswamy@linux.intel.com> <20210823195409-mutt-send-email-mst@kernel.org> <26a3cce5-ddf7-cbe6-a41e-58a2aea48f78@linux.intel.com> <20210824053830-mutt-send-email-mst@kernel.org> MIME-Version: 1.0 In-Reply-To: Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=mst@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Disposition: inline Cc: "Kuppuswamy, Sathyanarayanan" , Kuppuswamy Sathyanarayanan , Linux Doc Mailing List , Peter Zijlstra , Linux PCI , linux-mips@vger.kernel.org, James E J Bottomley , Dave Hansen , Peter H Anvin , sparclinux@vger.kernel.org, Thomas Gleixner , linux-arch , Jonathan Corbet , Helge Deller , X86 ML , Ingo Molnar , Arnd Bergmann , Tony Luck , Borislav Petkov , Andy Lutomirski , Bjorn Helgaas , Dan Williams , virtualization@lists.linux-foundation.org, Richard Henderson , Thomas Bogendoerfer , linux-parisc@vger.kernel.org, Sean Christopherson , Linux Kernel Mailing List , linux-alpha@vger.kernel.org, "David S . Miller" , Kirill Shutemov X-BeenThere: virtualization@lists.linux-foundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Linux virtualization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: virtualization-bounces@lists.linux-foundation.org Sender: "Virtualization" On Tue, Aug 24, 2021 at 10:20:44AM -0700, Andi Kleen wrote: > > > I see. Hmm. It's a bit of a random thing to do it at the map time > > though. E.g. DMA is all handled transparently behind the DMA API. > > Hardening is much more than just replacing map with map_shared > > and I suspect what you will end up with is basically > > vendors replacing map with map shared to make things work > > for their users and washing their hands. > > That concept exists too. There is a separate allow list for the drivers. So > just adding shared to a driver is not enough, until it's also added to the > allowlist > > Users can of course chose to disable the allowlist, but they need to > understand the security implications. Right. So given that, why do we need to tweak a random API like the map? If you just make all maps be shared then the user is in control. Seems sensible to me. > > > > > I would say an explicit flag in the driver that says "hardened" > > and refusing to init a non hardened one would be better. > > > We have that too (that's the device filtering) > > But the problem is that device filtering just stops the probe functions, not > the initcalls, and lot of legacy drivers do MMIO interactions before going > into probe. In some cases it's unavoidable because of the device doesn't > have a separate enumeration mechanism it needs some kind of probing to even > check for its existence And since we don't want to change all of them it's > far safer to make the ioremap opt-in. > > > -Andi Let's be frank, even without encryption disabling most drivers - especially weird ones that poke at hardware before probe - is far safer than keeping them, but one loses a bunch of features. IOW all this hardening is nice but which security/feature tradeoff to take it a policy decision, not something kernel should do imho. -- MST _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization