Received: by 2002:a25:ca44:0:0:0:0:0 with SMTP id a65csp2223224ybg; Thu, 30 Jul 2020 13:46:02 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzYy0UQtrVE3iAEE3llWHyfCvsWbgNHSDmlcBd8WnLS/bC+E15anZCz8E/U5CXzdqRI5o1S X-Received: by 2002:a17:906:3b4e:: with SMTP id h14mr934144ejf.546.1596141961889; Thu, 30 Jul 2020 13:46:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1596141961; cv=none; d=google.com; s=arc-20160816; b=uHOtLQgsxTVXDd18m18s/aWvcZSt4At1TVuICclhnAzyHLtt83K6iTMadwrr5NcFr6 lYLGiYO2WrECAZp8kA4sHwIexWGwa5uMR3y2IgDkC6V89K8HhQZExJdp3oHZ6N68dBpz Tm5pKKlLu6eZzXXhnMt5TpBwF/FgBSkJ78Sx4W3omUU3iWW0im/NHQP8mNFD1cRvy19B nGDDf2mkfir+QMAERR32I+q/T6O1T7M5eUeFHHRoIM11ibPoii/Q9aTNoCcDHlt6fusS T/tfMv3mqXlLKIyk+DTYfHLrLQpc1l3ldpLj1qZjmZxXBIpsdJtJ3DXcfnYRSAVA2Upd 0IIg== 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 :in-reply-to:references:mime-version; bh=5i7Uzc0vekDLme7wzIbvpCUOBwecLH5wlhKK6UAEgsM=; b=kjYW95m6T1FbQ9tE/deBOPBPHQTn04HSCvXNmg0Nn3/SNCfdIF5d6C5bBBnq5sgkXv q76SPU0DbHEwbRiLDXWh2ZILkfZ3p5ervlQhfVSVaUMnz6i8SW5jc8rgc+ZG3r18/hhO CginagEyPaW+2I2HW6rarrrmsmbv+/8dp6aElk7zcM9rxum7OVoAtbJKsbFg8KwOh0yX ZhurVhpCTtxev5z4XWsLpS2NfbcGaeLDuX+1azYW9DoM3s3E6+m1mrruGDoGtVJGfa1e ZCR+wwrDznKM0gqIBSl8xapOq+GY5MGinqS4vuDOGdzzSSDlUCFAJh6OZ78brFEuKaZV a2WQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y8si3838709edo.253.2020.07.30.13.45.38; Thu, 30 Jul 2020 13:46:01 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728778AbgG3UpW (ORCPT + 99 others); Thu, 30 Jul 2020 16:45:22 -0400 Received: from mout.kundenserver.de ([212.227.126.131]:33665 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728581AbgG3UpV (ORCPT ); Thu, 30 Jul 2020 16:45:21 -0400 Received: from mail-qt1-f181.google.com ([209.85.160.181]) by mrelayeu.kundenserver.de (mreue011 [212.227.15.129]) with ESMTPSA (Nemesis) id 1M6lYs-1k8OYb2gtq-008McS; Thu, 30 Jul 2020 22:45:19 +0200 Received: by mail-qt1-f181.google.com with SMTP id k18so21393727qtm.10; Thu, 30 Jul 2020 13:45:19 -0700 (PDT) X-Gm-Message-State: AOAM531J2zhpQnBnSWy7WpypqOSy3L7fHv9AgaQCkKFsPxJO7hqJAoLM rIFLexxTo/WXqqRM2SXwJ1ajKKLRGxEtFVcZ62Q= X-Received: by 2002:ac8:688e:: with SMTP id m14mr527498qtq.7.1596141918397; Thu, 30 Jul 2020 13:45:18 -0700 (PDT) MIME-Version: 1.0 References: <20200728141946.426245-1-yepeilin.cs@gmail.com> <20200729115157.8519-1-yepeilin.cs@gmail.com> <20200729125820.GB1840@kadam> <202007301056.D3BD1805B0@keescook> In-Reply-To: <202007301056.D3BD1805B0@keescook> From: Arnd Bergmann Date: Thu, 30 Jul 2020 22:45:02 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [Linux-kernel-mentees] [PATCH v2] block/floppy: Prevent kernel-infoleak in raw_cmd_copyout() To: Kees Cook Cc: Denis Efremov , Dan Carpenter , Peilin Ye , Jens Axboe , "linux-kernel@vger.kernel.org" , linux-block , linux-kernel-mentees@lists.linuxfoundation.org Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:3L5qp2rCNnf3YKbaKvTM/I14TgkbxDLotK+kqGmDy5kv4EqWsvY 3YK9zFJKiRQNiKkcEWviVvPXF2YKH9azX3merS/u7E5ku0lGK2BEe6BuWGv7kY5h5FlIikK YUCRJcPj1GqQ9yFyjA1YYd4Tx3YaLrrASAx2OPJt7Nc46c/Df2RhdUBV3jNqAkc7PhvNDJf gMZxAXzaYFpayG0pNqxwA== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:/5YeVEoM2Sg=:nT7UgV1osmuaiQ4kDFWQPL nd3TosOlVgCBOmD3RUGWJN22gSmwUE7EKzPxDnZy7ekwzA/kjt034CrsBrKVcd011YdfhXdxa q7XCmk/Z57h7/21fuXc0gQj9JC6w0qaz84NiveAb0Ahw6tbt04iIQmVFjfojovGrZtwwCk9M8 A7TCkJK426vPExANzFKy3+TNNs/NvRbZ1e5VgGLg1/7AyaIkZh7zDl4M0FCEGzMvH1ETYh1pe e8IkSj64NP1KycYRc5yymYVUOAhaze3Y1a4BaszFwnuNQY/UYoLNywDADLdau7LS8hEtXfQ+6 gSs8z3CwtnIL03aeIEKWQ5k5XfdTmHnhBGl+eaL2XMkmfmh6r2tLBibQvXwPuZ5d2j7LMQ2vn SdKAVDvQcwFJvs5eIsmJhiKApw8IPfgKRcJtn39eYtNjyqdD2IPYpNrdmGXTP6eFBtf9/FJUV DIdgVzo9ye8+OIySluFU/GLu6r+gcKlJj9GiieJPkeScAs3JZpOXqdpqXZJEmpQOdyTSPcRzQ TQqe9XaM+I+APLPH0Er3tpa9AzL/sjRhvs2aSKDBLcnOBvKC2Du/Gw0jsfwwWokEWkeaeXVNr QtQmgSUi7PYw9psITg799Hsje4dzEpR2DvOFqgPpF5Y69q7SlLtQx/u2bRVKHhYyxvQV2M8XV /3PSmXZRV642274DUpzIOyREZMx4UM6M3wH3iLoTewvi+t2G/42R5xqLc3Tno3mOum5iqjsqI XVTOKmvaAaQMbvpwCWHvrg7ObrNx8eNfViX3R2nEMFe66FQPBeZ0VwX6hqelpkssMcdZnaGJh NvlMHyamLX64dCEs5JvR/NsRkbrSIuxQLzUnfgad65ZVdtK2MbwKdHB34iXBQKbKQgaj4gS Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jul 30, 2020 at 8:10 PM Kees Cook wrote: > On Thu, Jul 30, 2020 at 10:11:07AM +0200, Arnd Bergmann wrote: > > test_stackinit.c intended to use six cases (where "full" is in the sense > of "all members are named", this is intentionally testing the behavior > of padding hole initialization): Ok, so I read that correctly, thanks for confirming. > > > > struct test_big_hole var = *arg; > > So this one is a "whole structure copy" which I didn't have any tests > for, since I'd (perhaps inappropriately) assumed would be accomplished > with memcpy() internally, which means the incoming "*arg"'s padding holes > would be copied as-is. If the compiler is actually doing per-member copies > and leaving holes in "var" untouched, that's unexpected, so clearly that > needs to be added to test_stackinit.c! :) For some reason I remembered this not turning into a memcpy() somewhere, but I can't reproduce it in any of my recent attempts, just like what Denis found. > > or the a constructor like > > > > struct test_big_hole var; > > var = (struct test_big_hole){ .one = arg->one, .two=arg->two, .three > > = arg->three, .four = arg->four }; > > > > Kees, do you know whether those two would behave differently? > > Would it make sense to also check for those, or am I perhaps > > misreading your code and it already gets checked? > > I *think* the above constructor would be covered under "full runtime > init", but it does also seem likely it would be handled similarly to > the "whole structure copy" in the previous example. I would assume that at least with C99 it is more like the "whole structure copy", based on the standard language of "The value of the compound literal is that of an unnamed object initialized by the initializer list. If the compound literal occurs outside the body of a function, the object has static storage duration; otherwise, it has automatic storage duration associated with the enclosing block." > I will go add more tests... Thanks! Arnd