From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f199.google.com (mail-pf0-f199.google.com [209.85.192.199]) by kanga.kvack.org (Postfix) with ESMTP id E2CD46B0007 for ; Thu, 5 Jul 2018 17:02:17 -0400 (EDT) Received: by mail-pf0-f199.google.com with SMTP id l21-v6so1254058pff.3 for ; Thu, 05 Jul 2018 14:02:17 -0700 (PDT) Received: from mail-sor-f65.google.com (mail-sor-f65.google.com. [209.85.220.65]) by mx.google.com with SMTPS id bd11-v6sor2412181plb.131.2018.07.05.14.02.16 for (Google Transport Security); Thu, 05 Jul 2018 14:02:16 -0700 (PDT) MIME-Version: 1.0 References: <20180627160800.3dc7f9ee41c0badbf7342520@linux-foundation.org> <20180628124039.8a42ab5e2994fb2876ff4f75@linux-foundation.org> <20180629194117.01b2d31e805808eee5c97b4d@linux-foundation.org> <20180702122112.267261b1e1609cf522753cf3@linux-foundation.org> In-Reply-To: From: Nick Desaulniers Date: Fri, 6 Jul 2018 06:02:04 +0900 Message-ID: Subject: Re: [PATCH v4 00/17] khwasan: kernel hardware assisted address sanitizer Content-Type: multipart/alternative; boundary="000000000000b088ae057046dc1f" Sender: owner-linux-mm@kvack.org List-ID: To: Evgenii Stepanov Cc: Andrew Morton , Andrey Konovalov , Andrey Ryabinin , Alexander Potapenko , Dmitry Vyukov , Catalin Marinas , Will Deacon , Christoph Lameter , Mark Rutland , Marc Zyngier , Dave Martin , Ard Biesheuvel , "Eric W . Biederman" , Ingo Molnar , Paul Lawrence , Geert Uytterhoeven , Arnd Bergmann , "Kirill A . Shutemov" , Greg Kroah-Hartman , Kate Stewart , Mike Rapoport , kasan-dev , linux-doc@vger.kernel.org, LKML , Linux ARM , linux-sparse@vger.kernel.org, Linux Memory Management List , Linux Kbuild mailing list , Kostya Serebryany , Lee Smith , Ramana Radhakrishnan , Jacob Bramley , Ruben Ayrapetyan , Jann Horn , Mark Brand , Chintan Pandya --000000000000b088ae057046dc1f Content-Type: text/plain; charset="UTF-8" On Tue, Jul 3, 2018, 5:22 AM Evgenii Stepanov wrote: > On Mon, Jul 2, 2018 at 12:21 PM, Andrew Morton > wrote: > > On Mon, 2 Jul 2018 12:16:42 -0700 Evgenii Stepanov > wrote: > > > >> On Fri, Jun 29, 2018 at 7:41 PM, Andrew Morton > >> wrote: > >> > On Fri, 29 Jun 2018 14:45:08 +0200 Andrey Konovalov < > andreyknvl@google.com> wrote: > >> > > >> >> >> What kind of memory consumption testing would you like to see? > >> >> > > >> >> > Well, 100kb or so is a teeny amount on virtually any machine. I'm > >> >> > assuming the savings are (much) more significant once the machine > gets > >> >> > loaded up and doing work? > >> >> > >> >> So with clean kernel after boot we get 40 kb memory usage. With KASAN > >> >> it is ~120 kb, which is 200% overhead. With KHWASAN it's 50 kb, which > >> >> is 25% overhead. This should approximately scale to any amounts of > >> >> used slab memory. For example with 100 mb memory usage we would get > >> >> +200 mb for KASAN and +25 mb with KHWASAN. (And KASAN also requires > >> >> quarantine for better use-after-free detection). I can explicitly > >> >> mention the overhead in %s in the changelog. > >> >> > >> >> If you think it makes sense, I can also make separate measurements > >> >> with some workload. What kind of workload should I use? > >> > > >> > Whatever workload people were running when they encountered problems > >> > with KASAN memory consumption ;) > >> > > >> > I dunno, something simple. `find / > /dev/null'? > >> > > >> > >> Looking at a live Android device under load, slab (according to > >> /proc/meminfo) + kernel stack take 8-10% available RAM (~350MB). > >> Kasan's overhead of 2x - 3x on top of it is not insignificant. > >> > > > > (top-posting repaired. Please don't) > > > > For a debugging, not-for-production-use feature, that overhead sounds > > quite acceptable to me. What problems is it known to cause? > > Not having this overhead enables near-production use - ex. running > kasan/khasan kernel on a personal, daily-use device to catch bugs that > do not reproduce in test configuration. These are the ones that often > cost the most engineering time to track down. > > CPU overhead is bad, but generally tolerable. RAM is critical, in our > experience. Once it gets low enough, OOM-killer makes your life > miserable. > This would be great actually. It's hard internally to get testers to run KASAN builds on their daily devices. I would prefer even if we didn't ship in production, to at least have internal testers using this build, as we have great panic reporting/collection. > --000000000000b088ae057046dc1f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


= On Tue, Jul 3, 2018, 5:22 AM Evgenii Stepanov <eugenis@google.com> wrote:
On Mon, Jul 2, 2018 at 12:21 PM, Andrew Morton
<akpm@linux-foundation.org> wrote:
> On Mon, 2 Jul 2018 12:16:42 -0700 Evgenii Stepanov <eugenis@google.= com> wrote:
>
>> On Fri, Jun 29, 2018 at 7:41 PM, Andrew Morton
>> <akpm@linux-foundation.org> wrote:
>> > On Fri, 29 Jun 2018 14:45:08 +0200 Andrey Konovalov <an= dreyknvl@google.com> wrote:
>> >
>> >> >> What kind of memory consumption testing would yo= u like to see?
>> >> >
>> >> > Well, 100kb or so is a teeny amount on virtually any= machine.=C2=A0 I'm
>> >> > assuming the savings are (much) more significant onc= e the machine gets
>> >> > loaded up and doing work?
>> >>
>> >> So with clean kernel after boot we get 40 kb memory usage= . With KASAN
>> >> it is ~120 kb, which is 200% overhead. With KHWASAN it= 9;s 50 kb, which
>> >> is 25% overhead. This should approximately scale to any a= mounts of
>> >> used slab memory. For example with 100 mb memory usage we= would get
>> >> +200 mb for KASAN and +25 mb with KHWASAN. (And KASAN als= o requires
>> >> quarantine for better use-after-free detection). I can ex= plicitly
>> >> mention the overhead in %s in the changelog.
>> >>
>> >> If you think it makes sense, I can also make separate mea= surements
>> >> with some workload. What kind of workload should I use? >> >
>> > Whatever workload people were running when they encountered p= roblems
>> > with KASAN memory consumption ;)
>> >
>> > I dunno, something simple.=C2=A0 `find / > /dev/null'?=
>> >
>>
>> Looking at a live Android device under load, slab (according to >> /proc/meminfo) + kernel stack take 8-10% available RAM (~350MB). >> Kasan's overhead of 2x - 3x on top of it is not insignificant.=
>>
>
> (top-posting repaired.=C2=A0 Please don't)
>
> For a debugging, not-for-production-use feature, that overhead sounds<= br> > quite acceptable to me.=C2=A0 What problems is it known to cause?

Not having this overhead enables near-production use - ex. running
kasan/khasan kernel on a personal, daily-use device to catch bugs that
do not reproduce in test configuration. These are the ones that often
cost the most engineering time to track down.

CPU overhead is bad, but generally tolerable. RAM is critical, in our
experience. Once it gets low enough, OOM-killer makes your life
miserable.

This would be great actually. It's hard internally to get tes= ters to run KASAN builds on their daily devices. I would prefer even if we = didn't ship in production, to at least have internal testers using this= build, as we have great panic reporting/collection.
--000000000000b088ae057046dc1f--