Received: by 2002:a25:2c96:0:0:0:0:0 with SMTP id s144csp643590ybs; Sun, 24 May 2020 16:48:46 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyzCggF+RfPq4Ot6afIQaUnA/qc/5b8UqoN7FBBG0HTQMr+SL69qzLAvN/gnr6a/chENGiH X-Received: by 2002:a17:906:4009:: with SMTP id v9mr16043125ejj.63.1590364126749; Sun, 24 May 2020 16:48:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1590364126; cv=none; d=google.com; s=arc-20160816; b=ypoi8fN/g7zRsDJ+qj3DHnOwOwU7R5yZ13ZVbQMIquQiVq8v7XEdLZhGQu8kQwrfr9 SGFYHChvrAnO4c+1rnDvZwGxYMITv/hb9z7d5LXRZnoXEWUurDc4WmOl3lvyWEpzUIok 8Lm1A38KZL+5d33lVjh57jzItm6YwpETNg/HtnCYspKJ86Ib76swLD7KSZGzFS83/x35 6vC1aZ6EycLNxD9C4KFB6Eko4ci6bTFMWNoPF+NVu+970ifAjZwq5riSFuz+kMitCpak sHb8rbTNz0WVn46S45USdhgyLImdreqr9krKkdKJzVnhrJmRxPcOMOdbLI0gUhztEoRP Tp+w== 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; bh=4A2LS3qr/ugDAiuTcUVKOiKX70TCKUv9nrW5wQ4ngRs=; b=gzJypcTLsmTcz5PlnqP3YDKqBNiWD5Q2ukpFFYfkDyVyVdY8ejNNF7W/UarNAWiMmZ f8Eh1/f+QbF+MWHDtYklRk5nYu5pR3io65TAwUvbLhSSdek3NbAJh93HZdNqVg5va/ud xLYxQqaIr/U6WNzNW7jlCCmBT5JuZ6KMNP+woR87+fB3Ry72QWzi7mhiLT7QzMq1dMZP YtmL7c+9rGIvFJGy9kESQ1qi1PM771EjnmOXNVV5/QyYZ7URYM4BFLrhaCdwtU/oSuP8 dDI+eugkJcLRHQ+T1yQr9o+86O+x/bUmuQe+9Bo4etJi3LZ1khhBdHBJFnePYtUdpZM3 cj8A== 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 sb25si8284717ejb.177.2020.05.24.16.48.23; Sun, 24 May 2020 16:48:46 -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 S2388164AbgEXXpo (ORCPT + 99 others); Sun, 24 May 2020 19:45:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49534 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388039AbgEXXpo (ORCPT ); Sun, 24 May 2020 19:45:44 -0400 Received: from ZenIV.linux.org.uk (zeniv.linux.org.uk [IPv6:2002:c35c:fd02::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 355BDC061A0E for ; Sun, 24 May 2020 16:45:44 -0700 (PDT) Received: from viro by ZenIV.linux.org.uk with local (Exim 4.93 #3 (Red Hat Linux)) id 1jd0JD-00EuEH-AT; Sun, 24 May 2020 23:45:35 +0000 Date: Mon, 25 May 2020 00:45:35 +0100 From: Al Viro To: Alexander Potapenko Cc: Kees Cook , Andrew Morton , Alexey Dobriyan , LKML , sunhaoyl@outlook.com, x86@kernel.org Subject: Re: [PATCH] fs/binfmt_elf.c: allocate initialized memory in fill_thread_core_info() Message-ID: <20200524234535.GA23230@ZenIV.linux.org.uk> References: <20200419100848.63472-1-glider@google.com> <20200420153352.6682533e794f591dae7aafbc@linux-foundation.org> <202004201540.01C8F82B@keescook> <20200421034249.GB23230@ZenIV.linux.org.uk> <20200512010901.GQ23230@ZenIV.linux.org.uk> <20200512034400.GA1537486@ZenIV.linux.org.uk> <20200513033349.GR23230@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200513033349.GR23230@ZenIV.linux.org.uk> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 13, 2020 at 04:33:49AM +0100, Al Viro wrote: > FWIW, what I'm going to do is > * make all callers of copy_regset_to_user() pass 0 as pos > (there are very few exceptions - one on arm64, three on sparc32 > and five on sparc64; I hadn't dealt with arm64 one yet, but all > cases on sparc are handled) [snip] Any of that would be easy to backport, though. Several questions regaring XSAVE and friends: * do we ever run on XSAVE/XSAVES-capable hardware with XFEATURE_FP turned off? * is it possible for x86 to have gaps between the state components area as reported by CPUID 0x0d? IOW, can area for feature 2 (XFEATURE_YMM) to start *not* at 0x200 and can area for N start not right after the end of area for N-1 for some N > 2? I think I have an easy-to-backport solution, but I'm really confused about XFEATURE_FP situation...