linux-kernel - Re: [PATCH] dma-mapping: Lift address space checks out of debug code

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 4 Oct 2019 13:25:55 -0700
From:   Kees Cook <keescook@...omium.org>
To:     Robin Murphy <robin.murphy@....com>
Cc:     Christoph Hellwig <hch@....de>, Laura Abbott <labbott@...hat.com>,
        Marek Szyprowski <m.szyprowski@...sung.com>,
        Jesper Dangaard Brouer <brouer@...hat.com>,
        Allison Randal <allison@...utok.net>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Stephen Boyd <swboyd@...omium.org>,
        Dan Carpenter <dan.carpenter@...cle.com>,
        Semmle Security Reports <security-reports@...mle.com>,
        iommu@...ts.linux-foundation.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] dma-mapping: Lift address space checks out of debug code

On Fri, Oct 04, 2019 at 07:50:54PM +0100, Robin Murphy wrote:
> On 03/10/2019 22:38, Kees Cook wrote:
> > What do you think about the object_is_on_stack() check? That does a
> > dereference through "current" to find the stack bounds...
> 
> I guess it depends what the aim is - is it just to bail out of operations
> which have near-zero chance of working correctly and every chance of going
> catastrophically wrong, or to lay down strict argument checking for the API
> in general? (for cache-coherent devices, or if the caller is careful to
> ensure the appropriate alignment, DMA from a non-virtually-mapped stack can
> be *technically* fine, it's just banned in general because those necessary
> assumptions can be tricky to meet and aren't at all portable).

Okay, then since the vmap check is both the cheapest and the most
important to catch in the face of breaking everything, I'll move that
in and we can keep USB's other checks separately.

-- 
Kees Cook