From: Emrah Demir <ed@abdsec.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Freeman Zhang <freeman.zhang1992@gmail.com>,
linus971@gmail.com, kexec@lists.infradead.org
Subject: Re: Removal of the kernel code/data/bss resources does break kexec/kdump
Date: Thu, 14 Apr 2016 16:27:48 -0400 [thread overview]
Message-ID: <f80ca230bf1fab7527d355e535de305f@abdsec.com> (raw)
In-Reply-To: <CA+55aFwprUFh+cjB2fWmkMJ3Zgh6XSan0VO8Vr-80Qh0n0Rx+A@mail.gmail.com>
On 2016-04-14 13:40, Linus Torvalds wrote:
>
> Actually, %pK is horrible in /proc and /sys files, and does the wrong
> thing.
>
I agree with that, but for now there is no way to make things right in
/proc or /sys.
>
> A file access should use "file->f_cred", but the seq_file interface
> sadly doesn't expose any way to do that.
>
> I'll take a look, but it's non-trivial to get right. %pK turns out to
> have been seriously mis-designed, and is basically almost always a
> bug.
>
> Linus
In another way, maybe it's good to remove code dependencies on /proc
sensitive files like /proc/iomem.
Kees Coook: "it looks like at least Ubuntu's kernel security test suite
expects to find these entries (when it verifies that STRICT_DEVMEM
hasn't regressed)"
Freeman Zhang: "Removal of these information causes 'kexec/kdump' to
fail in the newer
kernel"
Removing such dependencies would make things better and code/bss/data
sections could be removed.
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2016-04-14 20:28 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-14 10:14 Removal of the kernel code/data/bss resources does break kexec/kdump Freeman Zhang
2016-04-14 11:07 ` Emrah Demir
2016-04-14 17:40 ` Linus Torvalds
2016-04-14 20:27 ` Emrah Demir [this message]
2016-04-15 1:02 ` Linus Torvalds
2016-04-15 4:41 ` Kees Cook
2016-04-15 15:46 ` Emrah Demir
2016-04-15 16:48 ` Linus Torvalds
2016-04-15 17:08 ` Emrah Demir
2016-04-19 9:04 ` Dave Young
2016-04-19 16:20 ` Linus Torvalds
2016-04-20 1:13 ` Dave Young
2016-04-14 11:26 ` Baoquan He
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=f80ca230bf1fab7527d355e535de305f@abdsec.com \
--to=ed@abdsec.com \
--cc=freeman.zhang1992@gmail.com \
--cc=kexec@lists.infradead.org \
--cc=linus971@gmail.com \
--cc=torvalds@linux-foundation.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.