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=-6.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,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 3ADC3C41537 for ; Mon, 30 Aug 2021 21:00:05 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1EDB160F6C for ; Mon, 30 Aug 2021 21:00:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236673AbhH3VA5 (ORCPT ); Mon, 30 Aug 2021 17:00:57 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:23173 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236021AbhH3VAy (ORCPT ); Mon, 30 Aug 2021 17:00:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1630357199; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ZDgZoaGxuF8+VxsBt8mWUj6L6RMapnQD42kDmE3TNZQ=; b=GH03Om/445Kfh0spCpfgBXGkgopeKaJKIqsbbIqGNoDmAlnZTvAthA2tI2dz9Aq5cuTnHb S/4bNzDF2aRH+g5BXDAau4HDRE6CwBE5H4ZiUVX0kxknRtFixsmYk2gTkESXfR+1kQusEc NugrIp20O33foRVdV+QJ3G9RR3jW/9o= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-315-1eeGDMyLMDqQAh5bM-2YhA-1; Mon, 30 Aug 2021 16:59:57 -0400 X-MC-Unique: 1eeGDMyLMDqQAh5bM-2YhA-1 Received: by mail-wm1-f70.google.com with SMTP id s197-20020a1ca9ce000000b002e72ba822dcso235891wme.6 for ; Mon, 30 Aug 2021 13:59:57 -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:content-transfer-encoding :in-reply-to; bh=ZDgZoaGxuF8+VxsBt8mWUj6L6RMapnQD42kDmE3TNZQ=; b=gxgyN/T/lZsc6fHqMCt6TtS6UzStpgQIjAB5+Iq0z87ZY4C79RQ3dO25gZUJdmYkqx RI9Ds94JFWqutrVy6FU7gzDtMGgRi47lobkic2cGf0ZgqIIvtKzBw0RLEfW/1nlVjOr5 897FXI07aD1lYbTjhAGiAWdmFASpLFDUgQaOhR8uMs/VgVj/vvTA+231WlrJ68zR4F74 f34yf/xqL3sOIkgLOB57wt1PAMkqJ7RYpVANxf3I5Eursp5nLo56JRGTlgObtmrw8kWs /pEVfNjfWzrN5oezAPCrZYNKMLds+VPM7FPeHcIZXVu64eFDH4dkCJAAye22ODQAaH+t LPNw== X-Gm-Message-State: AOAM5306m1lPK6dTKWRpPjjmrQ/6ZF1aneqOJNrimtFFFfIbnbugdQMH 2lqelVS+St6O9G3M+8cVL98BSgUdmCu+o/KT+Rw4+dr3DH8aO5r8lGrfy46I3C6dGOOsJuT2g7i yqZxKQWmaMjo9IQGaEsSs X-Received: by 2002:a1c:7f48:: with SMTP id a69mr887119wmd.166.1630357196518; Mon, 30 Aug 2021 13:59:56 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxjS6eag15Cf7xmVDHk/qvmWoQLzIdnk7dLXkY7XjvOHcTw6SiXs3ksmYcUzh73pyrAtLIGDA== X-Received: by 2002:a1c:7f48:: with SMTP id a69mr887093wmd.166.1630357196296; Mon, 30 Aug 2021 13:59:56 -0700 (PDT) Received: from redhat.com ([2.55.138.60]) by smtp.gmail.com with ESMTPSA id z9sm12277068wre.11.2021.08.30.13.59.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 30 Aug 2021 13:59:55 -0700 (PDT) Date: Mon, 30 Aug 2021 16:59:50 -0400 From: "Michael S. Tsirkin" To: Andi Kleen Cc: Dan Williams , "Kuppuswamy, Sathyanarayanan" , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Peter Zijlstra , Andy Lutomirski , Bjorn Helgaas , Richard Henderson , Thomas Bogendoerfer , James E J Bottomley , Helge Deller , "David S . Miller" , Arnd Bergmann , Jonathan Corbet , Peter H Anvin , Dave Hansen , Tony Luck , Kirill Shutemov , Sean Christopherson , Kuppuswamy Sathyanarayanan , X86 ML , Linux Kernel Mailing List , Linux PCI , linux-alpha@vger.kernel.org, linux-mips@vger.kernel.org, linux-parisc@vger.kernel.org, sparclinux@vger.kernel.org, linux-arch , Linux Doc Mailing List , virtualization@lists.linux-foundation.org Subject: Re: [PATCH v4 11/15] pci: Add pci_iomap_shared{,_range} Message-ID: <20210830163723-mutt-send-email-mst@kernel.org> References: <20210823195409-mutt-send-email-mst@kernel.org> <26a3cce5-ddf7-cbe6-a41e-58a2aea48f78@linux.intel.com> <20210824053830-mutt-send-email-mst@kernel.org> <20210829112105-mutt-send-email-mst@kernel.org> <09b340dd-c8a8-689c-4dad-4fe0e36d39ae@linux.intel.com> <20210829181635-mutt-send-email-mst@kernel.org> <3a88a255-a528-b00a-912b-e71198d5f58f@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3a88a255-a528-b00a-912b-e71198d5f58f@linux.intel.com> Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org On Sun, Aug 29, 2021 at 10:11:46PM -0700, Andi Kleen wrote: > > On 8/29/2021 3:26 PM, Michael S. Tsirkin wrote: > > On Sun, Aug 29, 2021 at 09:17:53AM -0700, Andi Kleen wrote: > > > Also I changing this single call really that bad? It's not that we changing > > > anything drastic here, just give the low level subsystem a better hint about > > > the intention. If you don't like the function name, could make it an > > > argument instead? > > My point however is that the API should say that the > > driver has been audited, > > We have that status in the struct device. If you want to tie the ioremap to > that we could define a ioremap_device() with a device argument and decide > based on that. But it's not the device that is audited. And it's not the device that might be secure or insecure. It's the driver. > Or we can add _audited to the name. ioremap_shared_audited? But it's not the mapping that has to be done in handled special way. It's any data we get from device, not all of it coming from IO, e.g. there's DMA and interrupts that all have to be validated. Wouldn't you say that what is really wanted is just not running unaudited drivers in the first place? > > > not that the mapping has been > > done in some special way. For example the mapping can be > > in some kind of wrapper, not directly in the driver. > > However you want the driver validated, not the wrapper. > > > > Here's an idea: > > > I don't think magic differences of API behavior based on some define are a > good idea.  That's easy to miss. Well ... my point is that actually there is no difference in API behaviour. the map is the same map, exactly same data goes to device. If anything any non-shared map is special in that encrypted data goes to device. > > That's a "COME FROM" in API design. > > Also it wouldn't handle the case that a driver has both private and shared > ioremaps, e.g. for BIOS structures. Hmm. Interesting. It's bios maps that are unusual and need to be private though ... > And we've been avoiding that drivers can self declare auditing, we've been > trying to have a separate centralized list so that it's easier to enforce > and avoids any cut'n'paste mistakes. > > -Andi Now I'm confused. What is proposed here seems to be basically that, drivers need to declare auditing by replacing ioremap with ioremap_shared. -- MST