public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Kees Cook <keescook@chromium.org>
Cc: Robin Murphy <robin.murphy@arm.com>,
	Christoph Hellwig <hch@lst.de>, Laura Abbott <labbott@redhat.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Jesper Dangaard Brouer <brouer@redhat.com>,
	Allison Randal <allison@lohutok.net>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Stephen Boyd <swboyd@chromium.org>,
	Dan Carpenter <dan.carpenter@oracle.com>,
	Semmle Security Reports <security-reports@semmle.com>,
	iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] dma-mapping: Lift address space checks out of debug code
Date: Sat, 5 Oct 2019 10:27:54 +0200	[thread overview]
Message-ID: <20191005082754.GB12308@lst.de> (raw)
In-Reply-To: <201910031438.A67C40B97C@keescook>

On Thu, Oct 03, 2019 at 02:38:43PM -0700, Kees Cook wrote:
> > I think it would be reasonable to pull the is_vmalloc_addr() check inline,
> > as that probably covers 90+% of badness (especially given vmapped stacks),
> > and as you say should be reliably cheap everywhere. Callers are certainly
> > expected to use dma_mapping_error() and handle failure, so refusing to do a
> > bogus mapping operation should be OK API-wise - ultimately if a driver goes
> > ahead and uses DMA_MAPPING_ERROR as an address anyway, that's not likely to
> > be any *more* catastrophic than if it did the same with whatever nonsense
> > virt_to_phys() of a vmalloc address had returned.
> 
> What do you think about the object_is_on_stack() check? That does a
> dereference through "current" to find the stack bounds...

I can be persuaded about just the vmalloc check as people tend to get
a lot of vmalloc alloctions without knowing these days.  But what I'd
really like to see is a new config option that enables relatively
cheap checks without the full dma debugging infrastructure.  That way
you can turn those on at least for all development builds, and can
easily benchmark having the checks vs not.

  parent reply	other threads:[~2019-10-05  8:28 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-02 20:46 [PATCH] dma-mapping: Lift address space checks out of debug code Kees Cook
2019-10-02 21:15 ` Robin Murphy
2019-10-02 23:58   ` Kees Cook
2019-10-03  0:03     ` Kees Cook
2019-10-03  9:42     ` Robin Murphy
2019-10-03 21:38       ` Kees Cook
2019-10-04 18:50         ` Robin Murphy
2019-10-04 20:25           ` Kees Cook
2019-10-05  8:27         ` Christoph Hellwig [this message]
2019-10-02 22:37 ` kbuild test robot
2019-10-03  0:05 ` kbuild test robot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191005082754.GB12308@lst.de \
    --to=hch@lst.de \
    --cc=allison@lohutok.net \
    --cc=brouer@redhat.com \
    --cc=dan.carpenter@oracle.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=iommu@lists.linux-foundation.org \
    --cc=keescook@chromium.org \
    --cc=labbott@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=robin.murphy@arm.com \
    --cc=security-reports@semmle.com \
    --cc=swboyd@chromium.org \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox