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 4FD37C43219 for ; Fri, 10 Sep 2021 09:54:43 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 396DF6113E for ; Fri, 10 Sep 2021 09:54:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232154AbhIJJzv (ORCPT ); Fri, 10 Sep 2021 05:55:51 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:22972 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232108AbhIJJzu (ORCPT ); Fri, 10 Sep 2021 05:55:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1631267679; 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=G3LlEYSRHK/bW1nfGLOGdZcifmv3HCR8Ukwhz+/9614=; b=ikADgu7dsxj3oA0dObSy86XbT460Cqls7uMImgqDa3NDIq4PhSGyFOqkgfoyWMaH3FpotA e5DP9lldq3+b5A+WADy70CoFl9nGd0tdMbr1SQ3fyWk9Wog8/7nL++nTqsQsw5I+EGCxcV MCDiTpyK3gCb14WVuLu6Mtbq70stHa8= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-150-4LSY_ytLNBq_cLUIccTHuA-1; Fri, 10 Sep 2021 05:54:37 -0400 X-MC-Unique: 4LSY_ytLNBq_cLUIccTHuA-1 Received: by mail-wm1-f69.google.com with SMTP id y188-20020a1c7dc5000000b002e80e0b2f87so716652wmc.1 for ; Fri, 10 Sep 2021 02:54:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=G3LlEYSRHK/bW1nfGLOGdZcifmv3HCR8Ukwhz+/9614=; b=vT2gDDk9gV4vXiBtjAJbcTs9dLCyfMcTWaj8vdiPod7ma25nhJpqYChnzp4SR0UHsd RtENTuiHMyl7JkX6gt0Pw8ftvG/Kb84P3zyuYiNw+6x1pHK36XMur4NYGJDtkI2aPhjl wCxgSPPT59OBFETOl3GIN3/J3EOOwn8yrBbRUYOtevEN8Sb/DBFIc50lwkddcPwo13+f dz7Jdlvh/lxqOx+STiDc9JvPUFEp/XLg8rg3zY0xcENxSl0ZCPCJiJRiZVXNoXAm3pb4 aupYSU7fCB+403X8r0y5ONznVxTetWxVnlHVH9OnNF/qMiY8O/42+oPYQwtD8qlfHHdp 306w== X-Gm-Message-State: AOAM5327lSaRI9tYCR/p3038X0EjF4/GwC0YtGe/BNobMv4jj9FAYQBE +OPSIu+MzO6D8SGgtIEfSMvPZMppgnrLCnQpWLu58JWJ8M1YhKDPRMvirBdEanlJOKspe/MZJ2+ wqtzKmixxkMTd/IdxmseaFWF7 X-Received: by 2002:adf:eb81:: with SMTP id t1mr8840995wrn.245.1631267676748; Fri, 10 Sep 2021 02:54:36 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzO0Y/+7P/8niNtl+CoPrjCVE7HuwDhOVv5eL0lpW28+D5kEKFv5EWjYMYsYF1r6EhbMvRO7w== X-Received: by 2002:adf:eb81:: with SMTP id t1mr8840971wrn.245.1631267676591; Fri, 10 Sep 2021 02:54:36 -0700 (PDT) Received: from redhat.com ([2.55.145.189]) by smtp.gmail.com with ESMTPSA id o7sm3686409wmc.46.2021.09.10.02.54.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 10 Sep 2021 02:54:34 -0700 (PDT) Date: Fri, 10 Sep 2021 05:54:28 -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: <20210910054044-mutt-send-email-mst@kernel.org> References: <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> <20210830163723-mutt-send-email-mst@kernel.org> <69fc30f4-e3e2-add7-ec13-4db3b9cc0cbd@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <69fc30f4-e3e2-add7-ec13-4db3b9cc0cbd@linux.intel.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Aug 30, 2021 at 05:23:17PM -0700, Andi Kleen wrote: > > On 8/30/2021 1:59 PM, Michael S. Tsirkin wrote: > > > > > 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? > > > Yes. Then ... let's do just that? > > > > > > 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. > > Auditing is declared on the device model level using a central allow list. Can we not have an init call allow list instead of, or in addition to, a device allow list? > But this cannot do anything to initcalls that run before probe, Can't we extend module_init so init calls are validated against the allow list? > that's why > an extra level of defense of ioremap opt-in is useful. OK even assuming this, why is pci_iomap opt-in useful? That never happens before probe - there's simply no pci_device then. > But it's not the > primary mechanism to declare a driver audited, that's the allow list. The > ioremap is just another mechanism to avoid having to touch a lot of legacy > drivers. > > If we agree on that then the original proposed semantics of "ioremap_shared" > may be acceptable? > > -Andi > It looks suspiciously like drivers self-declaring auditing to me which we both seem to agree is undesirable. What exactly is the difference? Or are you just trying to disable anything that runs before probe? In that case I don't see a reason to touch pci drivers though. These should be fine with just the device model list. -- MST