From: Al Viro <viro@zeniv.linux.org.uk>
To: Alexander Potapenko <glider@google.com>
Cc: Kees Cook <keescook@chromium.org>,
Andrew Morton <akpm@linux-foundation.org>,
Alexey Dobriyan <adobriyan@gmail.com>,
LKML <linux-kernel@vger.kernel.org>,
sunhaoyl@outlook.com, x86@kernel.org
Subject: Re: [PATCH] fs/binfmt_elf.c: allocate initialized memory in fill_thread_core_info()
Date: Mon, 25 May 2020 00:45:35 +0100 [thread overview]
Message-ID: <20200524234535.GA23230@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20200513033349.GR23230@ZenIV.linux.org.uk>
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...
next prev parent reply other threads:[~2020-05-24 23:45 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-19 10:08 [PATCH] fs/binfmt_elf.c: allocate initialized memory in fill_thread_core_info() glider
2020-04-19 10:10 ` Alexander Potapenko
2020-04-20 22:33 ` Andrew Morton
2020-04-20 22:41 ` Kees Cook
2020-04-21 3:42 ` Al Viro
2020-04-21 8:14 ` Alexander Potapenko
2020-05-12 1:09 ` Al Viro
2020-05-12 3:44 ` Al Viro
2020-05-12 8:20 ` Alexander Potapenko
2020-05-13 3:33 ` Al Viro
2020-05-24 23:45 ` Al Viro [this message]
2020-05-26 22:38 ` Al Viro
2020-05-27 12:08 ` Alexander Potapenko
2020-05-27 19:04 ` Borislav Petkov
2020-05-27 19:53 ` Al Viro
2020-05-27 20:09 ` Borislav Petkov
2020-04-21 12:54 ` Alexander Potapenko
2020-04-21 15:09 ` Jann Horn
2020-04-21 16:04 ` Yu-cheng Yu
2020-04-21 16:16 ` Jann Horn
2020-04-21 16:26 ` Yu-cheng Yu
2020-04-21 20:20 ` Kees Cook
2020-04-21 8:06 ` Alexander Potapenko
2020-05-27 21:55 ` Kees Cook
2020-04-21 8:00 ` Alexander Potapenko
Reply instructions:
You may reply publicly 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=20200524234535.GA23230@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=adobriyan@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=glider@google.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sunhaoyl@outlook.com \
--cc=x86@kernel.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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.