Date:   Thu, 11 Apr 2019 10:58:24 -0700
From:   Eric Biggers <ebiggers@kernel.org>
To:     Kees Cook <keescook@chromium.org>
Cc:     Geert Uytterhoeven <geert@linux-m68k.org>,
        Herbert Xu <herbert@gondor.apana.org.au>,
        linux-security-module <linux-security-module@vger.kernel.org>,
        Linux ARM <linux-arm-kernel@lists.infradead.org>,
        Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Laura Abbott <labbott@redhat.com>,
        Rik van Riel <riel@surriel.com>
Subject: Re: crypto: Kernel memory overwrite attempt detected to spans
 multiple pages
Message-ID: <20190411175823.GC225654@gmail.com>
References: <20190319170911.GB202956@gmail.com>
 <20190320185719.GB180195@gmail.com>
 <CAGXu5jL-5C1ZGZ1JgaNFqK-z1Pp1N1X8gD3_ysKTCa=omD+_VQ@mail.gmail.com>
 <20190321175122.GA1587@sol.localdomain>
 <20190410031734.GB7140@sol.localdomain>
 <CAGXu5j+SZ2+Zkc=Vp5CXQUHhiR9f_OOnca684JTRW3T0yXdaNQ@mail.gmail.com>
 <20190410190729.GA120258@gmail.com>
 <CAGXu5j+Gfvj9G6s_UQTw6hE11gJb1edt3BXzpbDQdc_dpcHgag@mail.gmail.com>
 <20190410231156.GB120258@gmail.com>
 <CAGXu5jKg+oN7yUY=N69U93afOVHBPgwz6Osf=eMDPfiwbzEqmw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAGXu5jKg+oN7yUY=N69U93afOVHBPgwz6Osf=eMDPfiwbzEqmw@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: linux-crypto-owner@vger.kernel.org
Precedence: bulk

On Wed, Apr 10, 2019 at 04:27:28PM -0700, Kees Cook wrote:
> On Wed, Apr 10, 2019 at 4:12 PM Eric Biggers <ebiggers@kernel.org> wrote:
> > You've explained *what* it does again, but not *why*.  *Why* do you want
> > hardened usercopy to detect copies across page boundaries, when there is no
> > actual buffer overflow?
> 
> But that *is* how it determines it was a buffer overflow: "if you
> cross page boundaries (of a non-compound allocation), it *is* a buffer
> overflow". This assertion, however, is flawed because many contiguous
> allocations are not marked as being grouped together when it reality
> they were. It was an attempt to get allocation size information out of
> the page allocator, similar to how slab can be queries about
> allocation size. I'm open to improvements here, since it's obviously
> broken in its current state. :)
> 
> -- 
> Kees Cook

Well, I'm still at a loss as to whether I'm actually supposed to "fix" this by
adding __GFP_COMP, or whether you're saying the option is broken anyway so I
shouldn't bother doing anything.  IIUC, even the kernel stack is still not
marked __GFP_COMP, so copies to/from the stack can trigger this too, despite
this being reported over 2 years ago
(http://lkml.iu.edu/hypermail/linux/kernel/1701.2/01450.html)?
CONFIG_HARDENED_USERCOPY_PAGESPAN is even disabled in syzbot because you already
said the option is broken and should not be used.

I worry that people will enable all the hardened usercopy options "because
security", then when the pagespan check breaks something they will disable all
hardened usercopy options, because they don't understand the individual options.
Providing broken options is actively harmful, IMO.

- Eric