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]

Date:   Thu, 2 Aug 2018 17:11:18 +0300
From:   Andrey Ryabinin <aryabinin@...tuozzo.com>
To:     Catalin Marinas <catalin.marinas@....com>,
        Dmitry Vyukov <dvyukov@...gle.com>
Cc:     Mark Rutland <mark.rutland@....com>,
        Kate Stewart <kstewart@...uxfoundation.org>,
        linux-doc@...r.kernel.org,
        "Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>,
        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>,
        Dave Martin <Dave.Martin@....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>,
        Andrey Konovalov <andreyknvl@...gle.com>,
        Lee Smith <Lee.Smith@....com>,
        Mike Rapoport <rppt@...ux.vnet.ibm.com>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Kostya Serebryany <kcc@...gle.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Ard Biesheuvel <ard.biesheuvel@...aro.org>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        LKML <linux-kernel@...r.kernel.org>,
        "Eric W . Biederman" <ebiederm@...ssion.com>,
        Ramana Radhakrishnan <Ramana.Radhakrishnan@....com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Ruben Ayrapetyan <Ruben.Ayrapetyan@....com>
Subject: Re: [PATCH v4 00/17] khwasan: kernel hardware assisted address
 sanitizer

On 08/02/2018 04:52 PM, Catalin Marinas wrote:
> 
>> If somebody has a practical idea how to detect these statically, let's
>> do it. Otherwise let's go with the traditional solution to this --
>> dynamic testing. The patch series show that the problem is not a
>> disaster and we won't need to change just every line of kernel code.
> 
> It's indeed not a disaster but we had to do this exercise to find out
> whether there are better ways of detecting where untagging is necessary.
> 
> If you want to enable khwasan in "production" and since enabling it
> could potentially change the behaviour of existing code paths, the
> run-time validation space doubles as we'd need to get the same code
> coverage with and without the feature being enabled. I wouldn't say it's
> a blocker for khwasan, more like something to be aware of.
> 
> The awareness is a bit of a problem as the normal programmer would have
> to pay more attention to conversions between pointer and long. Given
> that this is an arm64-only feature, we have a risk of khwasan-triggered
> bugs being introduced in generic code in the future (hence the
> suggestion of some static checker, if possible).
 
I don't see how we can implement such checker. There is no simple rule which defines when we need
to remove the tag and when we can leave it in place.
The cast to long have nothing to do with the need to remove the tag. If pointers compared for sorting objects,
or lock ordering, than having tags is fine and it doesn't matter whether pointers compared as 'unsigned long'
or as 'void *'.
If developer needs to check whether the pointer is in linear mapping, than tag has to be removed.
But again, it doesn't matter if pointer is 'unsigned long' or 'void *'. Either way, the tag has to go away.