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=-8.3 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_IN_DEF_DKIM_WL 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 1DBA5C5DF60 for ; Tue, 5 Nov 2019 15:02:20 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C5618214D8 for ; Tue, 5 Nov 2019 15:02:19 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="nUGTNXPg" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C5618214D8 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 528C86B0003; Tue, 5 Nov 2019 10:02:19 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4D9A86B0008; Tue, 5 Nov 2019 10:02:19 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3C9266B000A; Tue, 5 Nov 2019 10:02:19 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0222.hostedemail.com [216.40.44.222]) by kanga.kvack.org (Postfix) with ESMTP id 268256B0003 for ; Tue, 5 Nov 2019 10:02:19 -0500 (EST) Received: from smtpin19.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with SMTP id D51D2180AC14B for ; Tue, 5 Nov 2019 15:02:18 +0000 (UTC) X-FDA: 76122539556.19.flame12_1406359b79e02 X-HE-Tag: flame12_1406359b79e02 X-Filterd-Recvd-Size: 6040 Received: from mail-wr1-f68.google.com (mail-wr1-f68.google.com [209.85.221.68]) by imf48.hostedemail.com (Postfix) with ESMTP for ; Tue, 5 Nov 2019 15:02:17 +0000 (UTC) Received: by mail-wr1-f68.google.com with SMTP id i10so1069707wrs.7 for ; Tue, 05 Nov 2019 07:02:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=pxRuzU7oPjb91+eUrwXYq6++ZiV4EfxQz6lWuVb3xXI=; b=nUGTNXPghKr0u3berBIC/wyTULXj7N8/pwv49iIpHbZZ431sLxDLb+1V64pCWT/ahs ftnKZyKVYCY2ZiY3Bn1HkPYjpC+AdtnrbGcwZPRlxRJwqs4yOei+5e+8TQCgIRBUecoF wwQo5I/gQjfoOZ/fruPjxlowXgiFx8e1TXF1HRYBCVcvbPPMoeEsY8bHWM8VN0IjNzO5 qZmW3G3Lt5dNjMHVP8jxVRkiEYcCKfyqnbvemGOYVmXHTXL0Film5IeHM7qliH8Ey6HQ aZhwV3vQRQw5V0cmNxFcQ6hJMm7WmaIcT4Jt00esoY433tcZ9H7OVxsogcZarmgKs131 lmBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=pxRuzU7oPjb91+eUrwXYq6++ZiV4EfxQz6lWuVb3xXI=; b=N/CeD1CvV1t92KIe0ND8mGhj1bCI1h/jAQGoWwCZN49yVW9CRjLKrEUVITEzS+Dj2D wqpLrT4OoqaTOTPEq3lAzYwX6tJ5jot4ufCm57Oe3jAD2GydA4jgxEV/luX3oteAeVKy ZOcK1Iguy75IO7foo3gjQeHjFiHbOy4axMDOxdrVVg+SAxOUfgwZRIlvWFCEybG1KgV6 2M0sWZRWIde3bgIUYJZMr7/U7aFS3vMwkAQ2r3Ut5l+39eo8T7h4Ez2mh9JaX2Rcz287 cqsfz/a9IRWsGBeu2Eh60E+6GBiBVq+GhYVlOS0AkOheOH7rL8BLHEilQeko4zLf2Rgi 4fEw== X-Gm-Message-State: APjAAAVJ3WVDdVD+4bJGraEo5p7kSXSp+zuJAKFy/yVkfdoffGEZ4Rgz aGi6K/1XsOcGZiYVCBVMuZgW+j2alTBUe7dFHB1qzQ== X-Google-Smtp-Source: APXvYqxDzkJdZsfLhM+GD8TQVcCA1f8EmCxvbdX/exxivUvZBFV8x6bX4oUWRWMrIfz/8KxWZjwcf+HjDObQjzGSB24= X-Received: by 2002:adf:9ec7:: with SMTP id b7mr28882683wrf.221.1572966135862; Tue, 05 Nov 2019 07:02:15 -0800 (PST) MIME-Version: 1.0 References: <20191030142237.249532-1-glider@google.com> <20191030142237.249532-23-glider@google.com> <20191030143814.GC15015@lst.de> In-Reply-To: <20191030143814.GC15015@lst.de> From: Alexander Potapenko Date: Tue, 5 Nov 2019 16:02:04 +0100 Message-ID: Subject: Re: [PATCH RFC v2 22/25] kmsan: unpoisoning buffers from devices etc. To: Christoph Hellwig Cc: Andrew Morton , Jens Axboe , "Theodore Ts'o" , Dmitry Torokhov , "Martin K. Petersen" , "Michael S. Tsirkin" , Eric Dumazet , Eric Van Hensbergen , Takashi Iwai , Vegard Nossum , Dmitry Vyukov , Matthew Wilcox , Linux Memory Management List , Al Viro , Andrey Ryabinin , Andy Lutomirski , Ard Biesheuvel , Arnd Bergmann , Greg Kroah-Hartman , Harry Wentland , Herbert Xu , Ingo Molnar , Martin Schwidefsky , Michal Simek , Petr Mladek , Sergey Senozhatsky , Steven Rostedt , Thomas Gleixner , Wolfram Sang , Vasily Gorbik , Ilya Leoshkevich , Mark Rutland , Randy Dunlap , Andrey Konovalov , Marco Elver Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Oct 30, 2019 at 3:38 PM Christoph Hellwig wrote: > > On Wed, Oct 30, 2019 at 03:22:34PM +0100, glider@google.com wrote: > > When data is copied to memory from a device KMSAN should treat it as > > initialized. In most cases it's enough to just unpoison the buffer that > > is known to come from a device. > > In the case with __do_page_cache_readahead() and bio_copy_user_iov() we > > have to mark the whole pages as ignored by KMSAN, as it's not obvious > > where these pages are read again. > > A lot of this looks pretty strange. Why don't you instrument > the dma_map / dma_sync infrastucture? That should avoid most of the > driver hooks. That's the exact reason I'm sending these patches: I simply don't know the kernel code good enough. May I ask you for some pointers? My goal is to mark data copied from the device as initialized (by calling kmsan_unpoison_shadow(ptr, size)), and, if possible, check data that's about to be copied to device (by calling kmsan_check_memory(ptr, size)). My understanding is that: 1. calls to dma_map_* and dma_sync_* with direction=3DDMA_FROM_DEVICE denote that the corresponding kernel buffer can be marked as initialized 2. calls to dma_unmap_* and dma_sync_* with direction=3DDMA_TO_DEVICE denote that the buffer will be copied to device (and must be checked for being initialized) 3. I need some translation table to find out the virtual address for a given dma_addr_t Does this sound reasonable? I still don't understand how to handle DMA_BIDIRECTIONAL. Will it be sane to assume that at each dma_{map,sync,unmap}_* call must always check the memory range and then unpoison it? Thanks in advance --=20 Alexander Potapenko Software Engineer Google Germany GmbH Erika-Mann-Stra=C3=9Fe, 33 80636 M=C3=BCnchen Gesch=C3=A4ftsf=C3=BChrer: Paul Manicle, Halimah DeLaine Prado Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg