Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp268535pxa; Fri, 31 Jul 2020 11:28:00 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzLvYipkbi0zpID8QIXULs2YL45MINV1YRuXWaSnTPanwzW+iHQT2tvHfhmTldQbWLb1AxZ X-Received: by 2002:a17:907:204e:: with SMTP id pg14mr5527261ejb.324.1596220080358; Fri, 31 Jul 2020 11:28:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1596220080; cv=none; d=google.com; s=arc-20160816; b=kJonz9rDoEy6zZBgD6uUQopD/yTmy6aXKsHll20gI14Ie4YxS/aIEN1TiUTHjuqRrs KNlwI+lvJOpyBRemuqr522Owm4+48iHXPDHiTZNQKnJKqW6TzGPu1WKUdo03EwcL/SJ3 iUWQe2nl9pewuLSApBFbKCV6c8nKZwlnnvXflepfTLTLE8AlugGc3XZDFCNMKSdONm6y W1TfkcP7PRkMB67Rbwx3CvHviUoBFMVNKaJtjhTDkfRY/kTXGfCwDVg5vRvuuxgMfQAq Iw8wO1akh+xyajVfxggt/NQgIrvs0xdxDWUtVy/lv8BHw8Rdl0433mgVMIVFbvrLY50c 1vjw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=tV7sc6wflPo/OY3J/lFfg1ZRZlhKID3SNfnVWUEEij0=; b=qoNNJq9Ux8mqSKZYvTzOJjHeb/6td2OcCRlIWQBKIGHju3T093bMmcRsjnKhnapZVa ZkG51aisHSr/jz7CTS+WFq5N8UvPGYDZimpelUx8Omrz30yR+0hUZ9hyhaOUTxlDeJcR Xw2L52D9wI1j8cfFN1bsx7XFdr0+1vpOvZExwmLMUkQRWtIsuScFtIK2yuqMshSEoRBc tPYkJR6ECwa49bd3kvGJI9iOwpOovxCnvw2STX9wZ5sJhDHRJ1Moc7kNxjtBxulBSonk i/ccXjwmgB6G9VjUa4ga4CXUBsiHnrktfRrh89E9XYIVz7qtNd7crg1/+G1BJZHIm1Bj Ztdg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ziepe.ca header.s=google header.b=jirAyMKB; 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 d4si5523813ejc.187.2020.07.31.11.27.38; Fri, 31 Jul 2020 11:28:00 -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; dkim=pass header.i=@ziepe.ca header.s=google header.b=jirAyMKB; 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 S2387793AbgGaS1P (ORCPT + 99 others); Fri, 31 Jul 2020 14:27:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58996 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387652AbgGaS1O (ORCPT ); Fri, 31 Jul 2020 14:27:14 -0400 Received: from mail-qt1-x841.google.com (mail-qt1-x841.google.com [IPv6:2607:f8b0:4864:20::841]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 21079C061574 for ; Fri, 31 Jul 2020 11:27:14 -0700 (PDT) Received: by mail-qt1-x841.google.com with SMTP id 6so23696755qtt.0 for ; Fri, 31 Jul 2020 11:27:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=tV7sc6wflPo/OY3J/lFfg1ZRZlhKID3SNfnVWUEEij0=; b=jirAyMKBcEnHMUKDFUsSmCToGT23RCdr6mO7c82AJACLIFDcftcqtQv7Y0rpjSOAZa 0Hh+Gkg0mXocP7OYRjdIhqSzcbiRWDUjAWJRAlUl4vtGGsHuEh74PRbLnc0uSwtOpuy/ +u+c664zqSnJ3ocdEv65VSLvGtOu1+TA+Le6rXbzmPjN1kTHwfPSCstj6EusTPHr06Ew tdI/nddtwUQsYmraBl7AGJhzOmKShzGAPGhJiypVRfJbrcIlL6IAyoF6oM05IjxYsHb0 HBkqvC6HByoBCfOx3KJBz8HksYdfzNIAYp7926RYYrbyoGblBM7e1pjBe8gPKE4MlaFM CWjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=tV7sc6wflPo/OY3J/lFfg1ZRZlhKID3SNfnVWUEEij0=; b=IVWHU/3aKjZ2koqoU+KDw3oPpbNwVJQvXKExSVj79W3Cg9WNwhIO3Gr0ukyLwBJ/Oh 3uveJ9lkOUAMSUWh0ffvuTFsUSZnEanfTvJ/BUOPqjRtnBoK/23GbsqkYTipp7q7nj0f l8lIDRV0eSk4y4JPwI7QEcMOfXi0GX1YVmepTsSYUY25wPp3S/EKt6jynz1sXEua2RLY 5dZ8OkwpFf1iLo3UOmoAPcDa2FQVEeX5ZLHtp0P2xgn6LwKLfajAe3Lu5RAmLaagtZ3b H484URcq6xYy/0f4zyCAwPq7gIeSWL5ezQgLt+n9w8qhpNqV+1vZq3Z44yki9+CUsfLM PZaA== X-Gm-Message-State: AOAM530iMUy8Q7SFfvI9E8TImiCkbhCaBwEswLLcmZk3vRUXFAcxKhRe JOtwnducUc7j4KF4jbEbavKN+g== X-Received: by 2002:ac8:8b3:: with SMTP id v48mr2085093qth.274.1596220033350; Fri, 31 Jul 2020 11:27:13 -0700 (PDT) Received: from ziepe.ca (hlfxns017vw-156-34-48-30.dhcp-dynamic.fibreop.ns.bellaliant.net. [156.34.48.30]) by smtp.gmail.com with ESMTPSA id x67sm9513983qke.136.2020.07.31.11.27.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 31 Jul 2020 11:27:12 -0700 (PDT) Received: from jgg by mlx with local (Exim 4.94) (envelope-from ) id 1k1ZkO-002AoB-41; Fri, 31 Jul 2020 15:27:12 -0300 Date: Fri, 31 Jul 2020 15:27:12 -0300 From: Jason Gunthorpe To: Greg Kroah-Hartman Cc: Leon Romanovsky , Peilin Ye , Santosh Shilimkar , "David S. Miller" , Jakub Kicinski , Dan Carpenter , Arnd Bergmann , linux-kernel-mentees@lists.linuxfoundation.org, netdev@vger.kernel.org, linux-rdma@vger.kernel.org, rds-devel@oss.oracle.com, linux-kernel@vger.kernel.org Subject: Re: [Linux-kernel-mentees] [PATCH net] rds: Prevent kernel-infoleak in rds_notify_queue_get() Message-ID: <20200731182712.GI24045@ziepe.ca> References: <20200730192026.110246-1-yepeilin.cs@gmail.com> <20200731045301.GI75549@unreal> <20200731053306.GA466103@kroah.com> <20200731053333.GB466103@kroah.com> <20200731140452.GE24045@ziepe.ca> <20200731142148.GA1718799@kroah.com> <20200731143604.GF24045@ziepe.ca> <20200731171924.GA2014207@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200731171924.GA2014207@kroah.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jul 31, 2020 at 07:19:24PM +0200, Greg Kroah-Hartman wrote: > > I tried for a bit and didn't find a way to get even old gcc 4.4 to not > > initialize the holes. > > Odd, so it is just the "= {0};" that does not zero out the holes? Nope, it seems to work fine too. I tried a number of situations and I could not get the compiler to not zero holes, even back to gcc 4.4 It is not just accidental either, take this: struct rds_rdma_notify { unsigned long user_token; unsigned char status; unsigned long user_token1 __attribute__((aligned(32))); } foo = {0}; Which has quite a big hole, clang generates: movq $0, 56(%rdi) movq $0, 48(%rdi) movq $0, 40(%rdi) movq $0, 32(%rdi) movq $0, 24(%rdi) movq $0, 16(%rdi) movq $0, 8(%rdi) movq $0, (%rdi) Deliberate extra instructions to fill both holes. gcc 10 does the same, older gcc's do create a rep stosq over the whole thing. Some fiddling with godbolt shows quite a variety of output, but I didn't see anything that looks like a compiler not filling padding. Even godbolt's gcc 4.1 filled the padding, which is super old. In several cases it seems the aggregate initializer produced better code than memset, in other cases it didn't Without an actual example where this doesn't work right it is hard to say anything more.. Jason