From: Dmitry Vyukov <email@example.com> To: "Uecker, Martin" <Martin.Uecker@med.uni-goettingen.de> Cc: "firstname.lastname@example.org" <email@example.com>, "firstname.lastname@example.org" <email@example.com>, "firstname.lastname@example.org" <email@example.com> Subject: Re: VLAs and security Date: Wed, 5 Sep 2018 09:35:09 +0200 Message-ID: <CACT4Y+aV8ts_v37RtovXC8epO+-JUwEb83cK3f-BeBFKjUKmNA@mail.gmail.com> (raw) In-Reply-To: <firstname.lastname@example.org> On Tue, Sep 4, 2018 at 8:22 PM, Uecker, Martin <Martin.Uecker@med.uni-goettingen.de> wrote: > Am Dienstag, den 04.09.2018, 10:00 +0200 schrieb Dmitry Vyukov: >> On Tue, Sep 4, 2018 at 8:27 AM, Uecker, Martin >> <Martin.Uecker@med.uni-goettingen.de> wrote: >> > Am Montag, den 03.09.2018, 14:28 -0700 schrieb Linus Torvalds: > > > Hi Dmitry, > >> Compiler and KASAN should still be able to do checking against the >> static array size. > > ...and it is probably true that this is currently more useful > than the limited amount of checking compilers can do for VLAs. > >> If you mean that there is some smaller dynamic logical bound n (<N) >> and we are not supposed to use memory beyond that, > > Yes, this is what I mean. > > My concern is that this dynamic bound is valuable information > which was put there by programmers by hand and I believe that > this information can not always be recovered automatically > by static analysis. So by removing VLAs from the source tree, > this information ist lost. > >> then KMSAN  can >> detect uses of the uninitialized part of the array. So we have some >> coverage on the checking side too. >> >>  https://github.com/google/kmsan#kmsan-kernelmemorysanitizer > > But detecting reads of uninitialized parts can detect only some > of the errors which could be detected with precise bounds. > It can not detect out-of-bounds writes (which still fall into > the larger fixed-size array) and it does not detect out-of-bounds > reads (which still fall into the larger fixed-size array) if > the larger fixed-size array was completely initialized > before for some reason. Well, I agree maybe it harms checking ability to some degree. But it's always tradeoffs all way down. And in the end nothing can safe from logical bugs (well, except for unit tests). With VLA one give a right bound but the use wrong bytes in the buffer, or simply give a wrong bound.
prev parent reply index Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-09-02 8:08 Uecker, Martin 2018-09-02 17:40 ` Kees Cook 2018-09-03 7:39 ` Uecker, Martin 2018-09-03 21:28 ` Linus Torvalds 2018-09-04 6:27 ` Uecker, Martin 2018-09-04 8:00 ` Dmitry Vyukov 2018-09-04 18:22 ` Uecker, Martin 2018-09-05 7:35 ` Dmitry Vyukov [this message]
Reply instructions: You may reply publically to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CACT4Y+aV8ts_v37RtovXC8epO+-JUwEb83cK3f-BeBFKjUKmNA@mail.gmail.com \ --email@example.com \ --cc=Martin.Uecker@med.uni-goettingen.de \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
LKML Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/lkml/0 lkml/git/0.git git clone --mirror https://lore.kernel.org/lkml/1 lkml/git/1.git git clone --mirror https://lore.kernel.org/lkml/2 lkml/git/2.git git clone --mirror https://lore.kernel.org/lkml/3 lkml/git/3.git git clone --mirror https://lore.kernel.org/lkml/4 lkml/git/4.git git clone --mirror https://lore.kernel.org/lkml/5 lkml/git/5.git git clone --mirror https://lore.kernel.org/lkml/6 lkml/git/6.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 lkml lkml/ https://lore.kernel.org/lkml \ email@example.com firstname.lastname@example.org public-inbox-index lkml Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel AGPL code for this site: git clone https://public-inbox.org/ public-inbox