From: Aili Yao <firstname.lastname@example.org> To: Tony Luck <email@example.com>, Borislav Petkov <firstname.lastname@example.org> Cc: email@example.com, firstname.lastname@example.org, email@example.com, "Andy Lutomirski" <firstname.lastname@example.org>, "HORIGUCHI NAOYA( 堀口 直也)" <email@example.com>, firstname.lastname@example.org Subject: Re: [RFC 0/4] Fix machine check recovery for copy_from_user Date: Thu, 8 Apr 2021 10:13:35 +0800 [thread overview] Message-ID: <20210408101335.28fd3692@alex-virtual-machine> (raw) In-Reply-To: <email@example.com> On Thu, 25 Mar 2021 17:02:31 -0700 Tony Luck <firstname.lastname@example.org> wrote: > Maybe this is the way forward? I made some poor choices before > to treat poison consumption in the kernel when accessing user data > (get_user() or copy_from_user()) ... in particular assuming that > the right action was sending a SIGBUS to the task as if it had > synchronously accessed the poison location. > > First three patches may need to be combined (or broken up differently) > for bisectablilty. But they are presented separately here since they > touch separate parts of the problem. > > Second part is definitley incomplete. But I'd like to check that it > is the right approach before expending more brain cells in the maze > of nested macros that is lib/iov_iter.c > > Last part has been posted before. It covers the case where the kernel > takes more than one swing at reading poison data before returning to > user. > > Tony Luck (4): > x86/mce: Fix copyin code to return -EFAULT on machine check. > mce/iter: Check for copyin failure & return error up stack > mce/copyin: fix to not SIGBUS when copying from user hits poison > x86/mce: Avoid infinite loop for copy from user recovery > > arch/x86/kernel/cpu/mce/core.c | 63 +++++++++++++++++++++--------- > arch/x86/kernel/cpu/mce/severity.c | 2 - > arch/x86/lib/copy_user_64.S | 18 +++++---- > fs/iomap/buffered-io.c | 8 +++- > include/linux/sched.h | 2 +- > include/linux/uio.h | 2 +- > lib/iov_iter.c | 15 ++++++- > 7 files changed, 77 insertions(+), 33 deletions(-) > I have one scenario, may you take into account: If one copyin case occurs, write() returned by your patch, the user process may check the return values, for errors, it may exit the process, then the error page will be freed, and then the page maybe alloced to other process or to kernel itself, then code will initialize it and this will trigger one SRAO, if it's used by kernel, we may do nothing for this, and kernel may still touch it, and lead to one panic. Is this we expect? Thanks! Aili Yao
next prev parent reply other threads:[~2021-04-08 2:13 UTC|newest] Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-03-26 0:02 Tony Luck 2021-03-26 0:02 ` [PATCH 1/4] x86/mce: Fix copyin code to return -EFAULT on machine check Tony Luck 2021-04-06 19:24 ` Borislav Petkov 2021-03-26 0:02 ` [PATCH 2/4] mce/iter: Check for copyin failure & return error up stack Tony Luck 2021-03-26 0:02 ` [PATCH 3/4] mce/copyin: fix to not SIGBUS when copying from user hits poison Tony Luck 2021-04-07 21:18 ` Borislav Petkov 2021-04-07 21:43 ` Luck, Tony 2021-04-08 8:49 ` Borislav Petkov 2021-04-08 17:08 ` Luck, Tony 2021-04-13 10:07 ` Borislav Petkov 2021-04-13 16:13 ` Luck, Tony 2021-04-14 13:05 ` Borislav Petkov 2021-03-26 0:02 ` [PATCH 4/4] x86/mce: Avoid infinite loop for copy from user recovery Tony Luck 2021-04-08 13:36 ` Borislav Petkov 2021-04-08 16:06 ` Luck, Tony 2021-04-08 2:13 ` Aili Yao [this message] 2021-04-08 14:39 ` [RFC 0/4] Fix machine check recovery for copy_from_user Luck, Tony 2021-04-09 6:49 ` Aili Yao
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=20210408101335.28fd3692@alex-virtual-machine \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [RFC 0/4] Fix machine check recovery for copy_from_user' \ /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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).