linux-kernel - Re: [PATCH v4 00/17] khwasan: kernel hardware assisted address sanitizer

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]

Message-ID: <20180629110706.37aqq6x4vhnblkb6@armageddon.cambridge.arm.com>
Date:   Fri, 29 Jun 2018 12:07:06 +0100
From:   Catalin Marinas <catalin.marinas@....com>
To:     Andrey Konovalov <andreyknvl@...gle.com>
Cc:     Dave Martin <Dave.Martin@....com>,
        Mark Rutland <mark.rutland@....com>,
        Kate Stewart <kstewart@...uxfoundation.org>,
        linux-doc@...r.kernel.org, Will Deacon <will.deacon@....com>,
        Paul Lawrence <paullawrence@...gle.com>,
        Linux Memory Management List <linux-mm@...ck.org>,
        Alexander Potapenko <glider@...gle.com>,
        Chintan Pandya <cpandya@...eaurora.org>,
        Christoph Lameter <cl@...ux.com>,
        Ingo Molnar <mingo@...nel.org>,
        Jacob Bramley <Jacob.Bramley@....com>,
        Jann Horn <jannh@...gle.com>,
        Mark Brand <markbrand@...gle.com>,
        kasan-dev <kasan-dev@...glegroups.com>,
        linux-sparse@...r.kernel.org,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Andrey Ryabinin <aryabinin@...tuozzo.com>,
        Evgeniy Stepanov <eugenis@...gle.com>,
        Arnd Bergmann <arnd@...db.de>,
        Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
        Marc Zyngier <marc.zyngier@....com>,
        Ramana Radhakrishnan <Ramana.Radhakrishnan@....com>,
        Ruben Ayrapetyan <Ruben.Ayrapetyan@....com>,
        Mike Rapoport <rppt@...ux.vnet.ibm.com>,
        Dmitry Vyukov <dvyukov@...gle.com>,
        Kostya Serebryany <kcc@...gle.com>,
        Ard Biesheuvel <ard.biesheuvel@...aro.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        LKML <linux-kernel@...r.kernel.org>,
        "Eric W . Biederman" <ebiederm@...ssion.com>,
        Lee Smith <Lee.Smith@....com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        "Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>
Subject: Re: [PATCH v4 00/17] khwasan: kernel hardware assisted address
 sanitizer

On Thu, Jun 28, 2018 at 08:56:41PM +0200, Andrey Konovalov wrote:
> On Thu, Jun 28, 2018 at 12:51 PM, Dave Martin <Dave.Martin@....com> wrote:
> > On Tue, Jun 26, 2018 at 03:15:10PM +0200, Andrey Konovalov wrote:
> >> 1. By using the Top Byte Ignore arm64 CPU feature, we can store pointer
> >>    tags in the top byte of each kernel pointer.
> >
> > [...]
> >
> > This is a change from the current situation, so the kernel may be
> > making implicit assumptions about the top byte of kernel addresses.
> >
> > Randomising the top bits may cause things like address conversions and
> > pointer arithmetic to break.
> >
> > For example, (q - p) will not produce the expected result if q and p
> > have different tags.
> 
> If q and p have different tags, that means they come from different
> allocations. I don't think it would make sense to calculate pointer
> difference in this case.

Well, there is a lot of pointer comparison in the kernel which means
pointer difference. Take is_vmalloc_addr() for example, even if your
patchset does not cover (IIUC) vmalloc() at the moment, this function
may be called with slab addresses. Presumably they would all fail the
check with a non-0xff tag but it's something needs understood. If you
later add support for vmalloc(), this test would fail (as would the
rb tree search in find_vmap_area(). Kmemleak would probably break as
well as it makes heavy use of rb tree.

Basically you need to be very clear about kernel pointer usage (with an
associated tag or type) vs address range it refers to and in most cases
converted to an unsigned long. See the other discussion on sparse, it
could potentially be useful if we can detect the places where a pointer
is converted to ulong and maybe hide such conversion behind a macro with
the arm64 implementation also clearing the tag.

-- 
Catalin