From: Andrew Morton <akpm@linux-foundation.org>
To: yalin wang <yalin.wang2010@gmail.com>
Cc: Ingo Molnar <mingo@kernel.org>,
dave@sr71.net, David Rientjes <rientjes@google.com>,
fabf@skynet.be, bhe@redhat.com,
open list <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] kcore:change kcore_read to make sure the kernel read is safe
Date: Tue, 4 Aug 2015 15:38:23 -0700 [thread overview]
Message-ID: <20150804153823.51b8ba7b9307dc663d635907@linux-foundation.org> (raw)
In-Reply-To: <593904DC-7E60-4B95-B82F-B50A5024085C@gmail.com>
On Tue, 4 Aug 2015 11:37:57 +0800 yalin wang <yalin.wang2010@gmail.com> wrote:
> This change kcore_read() to use __copy_from_user_inatomic() to
> copy data from kernel address, because kern_addr_valid() just make sure
> page table is valid during call it, whne it return, the page table may
> change, for example, like set_fixmap() function will change kernel page
> table, then maybe trigger kernel crash if encounter this unluckily.
The changelog is a bit hard to follow. How does this version look?
: read_kcore() does a copy_to_user() from kernel memory. This could cause a
: crash if the source (kernel) address is concurrently unmapped via, say,
: set_fixmap(). The kern_addr_valid() check is racy and won't reliably
: prevent this.
:
: Change kcore_read() to use __copy_from_user_inatomic() via a temporary
: buffer to catch such situations.
What actually happens when copy_to_user() gets a fault on the source
address? It *could* handle it and return -EFAULT. I forget...
Also... what is special about this particular copy_to_user()? Isn't
every copy_to_user() in the kernel vulnerable to a concurrent
set_fixmap()? Is it that only read_kcore() will read pages which are
subject to set_fixmap() alteration?
> --- a/fs/proc/kcore.c
> +++ b/fs/proc/kcore.c
> @@ -86,8 +86,8 @@ static size_t get_kcore_size(int *nphdr, size_t *elf_buflen)
> size = try;
> *nphdr = *nphdr + 1;
> }
> - *elf_buflen = sizeof(struct elfhdr) +
> - (*nphdr + 2)*sizeof(struct elf_phdr) +
> + *elf_buflen = sizeof(struct elfhdr) +
> + (*nphdr + 2)*sizeof(struct elf_phdr) +
Unrelated whitespace fixes really shouldn't be in here. They don't
bother me too much, but some people get upset ;)
> 3 * ((sizeof(struct elf_note)) +
> roundup(sizeof(CORE_STR), 4)) +
> roundup(sizeof(struct elf_prstatus), 4) +
> @@ -435,6 +435,7 @@ read_kcore(struct file *file, char __user *buffer, size_t buflen, loff_t *fpos)
> size_t elf_buflen;
> int nphdr;
> unsigned long start;
> + unsigned long page = 0;
"page" isn't a very good name - when we see that identifier we expect
it to be a `struct page *'. Maybe call it copy_buf or something.
(And incoming argument "buffer" was poorly named. "buffer" implies some
temporary intermediate thing, which is inappropriate here!)
> read_lock(&kclist_lock);
> size = get_kcore_size(&nphdr, &elf_buflen);
> @@ -485,7 +486,7 @@ read_kcore(struct file *file, char __user *buffer, size_t buflen, loff_t *fpos)
> start = kc_offset_to_vaddr(*fpos - elf_buflen);
> if ((tsz = (PAGE_SIZE - (start & ~PAGE_MASK))) > buflen)
> tsz = buflen;
> -
> +
> while (buflen) {
> struct kcore_list *m;
>
> @@ -515,15 +516,32 @@ read_kcore(struct file *file, char __user *buffer, size_t buflen, loff_t *fpos)
> } else {
> if (kern_addr_valid(start)) {
Do we still need the (racy) kern_addr_valid() test? The code should
work OK if this is removed?
> unsigned long n;
> + mm_segment_t old_fs = get_fs();
> +
> + if (page == 0) {
> + page = __get_free_page(GFP_KERNEL);
> + if (page == 0)
> + return -ENOMEM;
>
> - n = copy_to_user(buffer, (char *)start, tsz);
> + }
> + set_fs(KERNEL_DS);
> + pagefault_disable();
> + n = __copy_from_user_inatomic((void *)page,
> + (__force const void __user *)start,
> + tsz);
> + pagefault_enable();
> + set_fs(old_fs);
We should have a code comment in here telling people what's going on.
A concurrent set_fixmap() on the source memory is unexpected!
> + if (n)
> + memset((void *)page + tsz - n, 0, n);
> +
> + n = copy_to_user(buffer, (char *)page, tsz);
> /*
> * We cannot distinguish between fault on source
> * and fault on destination. When this happens
> * we clear too and hope it will trigger the
> * EFAULT again.
> */
> - if (n) {
> + if (n) {
> if (clear_user(buffer + tsz - n,
> n))
> return -EFAULT;
> @@ -540,7 +558,7 @@ read_kcore(struct file *file, char __user *buffer, size_t buflen, loff_t *fpos)
> start += tsz;
> tsz = (buflen > PAGE_SIZE ? PAGE_SIZE : buflen);
> }
> -
> + free_page(page);
> return acc;
> }
next prev parent reply other threads:[~2015-08-04 22:38 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-04 3:37 yalin wang
2015-08-04 21:18 ` Dave Hansen
2015-08-05 3:37 ` yalin wang
2015-08-04 22:38 ` Andrew Morton [this message]
2015-08-05 3:30 ` yalin wang
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=20150804153823.51b8ba7b9307dc663d635907@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=bhe@redhat.com \
--cc=dave@sr71.net \
--cc=fabf@skynet.be \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=rientjes@google.com \
--cc=yalin.wang2010@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®