Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp3487637imm; Wed, 5 Sep 2018 00:36:50 -0700 (PDT) X-Google-Smtp-Source: ANB0VdaRZ5mueIECZv/rnsfXlADhC7XVgd6ZwY/NzTj4zlFh+BwFpk4mKwcO3arK/+VtIUK0fIgw X-Received: by 2002:a17:902:5a4e:: with SMTP id f14-v6mr32446203plm.311.1536133010405; Wed, 05 Sep 2018 00:36:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536133010; cv=none; d=google.com; s=arc-20160816; b=VtAcM9A0WzMP1394XI3aiSjUN+7fnXU5ERWcaMKoz1TEwHxifwGjhboG/j8MGa/32l b2YZAUmBQ9uXH0/kj9pOvmCr45yQTkeUIGH7MeAHSXr2XR6Qsj43/d4uAEb9ZJ1TIwGc PsoCpnb6DNtItgZsfx8liPurgS9c9lj11iB+SgeQWCcezHSXhaH0IBOAjYqVSrkN2N9c 7icsCmarjS4mhZD7/0+6pTPtYIPOf1CdmNiRrXJca6ZAhMHSUguKcgeLTlcEwr7srGU2 3uy4zwuPooQhKnP+QG1nqfDOyGbVJ+dqxz/Rh0ly7fRkbCYclKL5SgtegDlXMLLdA76b sfrw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature; bh=gAA0J3VhrgEllC2yCTaYJU9g9OZ4dIWotsN9TXJfqjw=; b=y2u9m2rofQOn3NjExwzJSMYAU27JRSK/cvEkCGELSHU85ddRnnoGu4r79//S9nllBj HgI5AMLz2rpC7szALuTcPOJp+FvcEfNeOgrVmDJG5DF1KI+4xCLfy2/Be88mUulTB4T/ UmJfU6+guINJbzxZKQc7fFrCE4tK6HYTi9HthsBmqhkJdxSegIcbp0QY9VKrtIZ0bY+n ZfP/6DklfpV66+LKmKs+V0sJdcXEkDlTecYrrH0VxDlq/ML1tknTo/mDpYL3+QUMZg9T xpX0K22S7Z9/a+wyyjPc/WSzyH/vatvdvy3Uyw0W8cYx+dWN7DXQYSLjXQVZe80tEezP Vg4Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=aCTJoRyb; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q61-v6si1166889plb.231.2018.09.05.00.36.34; Wed, 05 Sep 2018 00:36:50 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=aCTJoRyb; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727527AbeIEMEY (ORCPT + 99 others); Wed, 5 Sep 2018 08:04:24 -0400 Received: from mail-pg1-f172.google.com ([209.85.215.172]:36730 "EHLO mail-pg1-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726242AbeIEMEX (ORCPT ); Wed, 5 Sep 2018 08:04:23 -0400 Received: by mail-pg1-f172.google.com with SMTP id d1-v6so3001652pgo.3 for ; Wed, 05 Sep 2018 00:35:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gAA0J3VhrgEllC2yCTaYJU9g9OZ4dIWotsN9TXJfqjw=; b=aCTJoRybIofn0azNkZpErhl3epsZ3+CaGx8jOo7XKACbs4ePdzLGveiquSFFu21/PI X2ciqNkPIX4P0vXBzOG5NuRxQOA6xOPi0r+QSu+5mGK/0Or29XQ0ZZdL/T7FLh/DdCHa eZkYKWCt+Zm3aHxarBRIXFqKFnK4zMG9Wi8TjBVs68ngQwCc07hs0GHouDMw56uutxkI koH4AfM7vj/8A74iiC98k9K0TvHoxfZJH/M4DjLEwl2oWhDipQEwmNW6yphdlyr8s5bJ SEUNg4ze//a1e7ZgS1z/b+Yx2KXgTp9A1KVMUqh6hZqJ9qLxKcaql/djlga1UwslfVCF i+1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gAA0J3VhrgEllC2yCTaYJU9g9OZ4dIWotsN9TXJfqjw=; b=mQ7GvvgH2tEOnA6mSgq3SMEk4zn7HeP2gjqS0dvNyoF+m4Wzdv/Mwuftov+Z3EAT5d OYYtW8SIQKze1RwlvXde6rT6CKOHPSzSUr11GCRsoaErCdx+nM/m0nruZ0vP+foLCgx9 9bMtLhVkgeDQ88mkTotaOPxIH+zwRmY7o5kZ9gJpgWHYsMd7mIQRDE0g9W6YVuoMk5VB DdNesSQP+eIV1/LnlSIKj80+ZYYiSHSgAG3Ua6uTaUTKIKOh+vsxVs79vB/7M8viD6Fb jZfttiEipLgYLc4A6y2edxgautLQi4tkjtSJRwrzTSXo54VjTQuJjjfiXZ253qmDpM7r ohqw== X-Gm-Message-State: APzg51C4f+NnLl6kYr3PWlJeMcYJ17Kauz6iXA1YzwZ7X7rig8+iDgaM eGlyLdA5GpVou4D0t9aWKsLigTgDJrMJ2Ik/BAUVYA== X-Received: by 2002:a62:4494:: with SMTP id m20-v6mr39138245pfi.205.1536132929916; Wed, 05 Sep 2018 00:35:29 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:ac14:0:0:0:0 with HTTP; Wed, 5 Sep 2018 00:35:09 -0700 (PDT) In-Reply-To: <1536085338.17991.1.camel@med.uni-goettingen.de> References: <1535875700.17858.3.camel@med.uni-goettingen.de> <1535960372.32005.1.camel@med.uni-goettingen.de> <1536042474.25086.1.camel@med.uni-goettingen.de> <1536085338.17991.1.camel@med.uni-goettingen.de> From: Dmitry Vyukov Date: Wed, 5 Sep 2018 09:35:09 +0200 Message-ID: Subject: Re: VLAs and security To: "Uecker, Martin" Cc: "torvalds@linux-foundation.org" , "keescook@chromium.org" , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Sep 4, 2018 at 8:22 PM, Uecker, Martin wrote: > Am Dienstag, den 04.09.2018, 10:00 +0200 schrieb Dmitry Vyukov: >> On Tue, Sep 4, 2018 at 8:27 AM, Uecker, Martin >> 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 (> 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 [1] can >> detect uses of the uninitialized part of the array. So we have some >> coverage on the checking side too. >> >> [1] 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.