From: catalin.marinas@arm.com (Catalin Marinas)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH trivial] arm64: constify hwcap_str
Date: Fri, 8 Nov 2013 17:19:49 +0000 [thread overview]
Message-ID: <20131108171949.GD17212@arm.com> (raw)
In-Reply-To: <CAKv+Gu_vvLmLxD_NfVzK16cRccXj9FOZwG39D39nqgedF3qVBA@mail.gmail.com>
On Fri, Nov 08, 2013 at 05:14:16PM +0000, Ard Biesheuvel wrote:
> On 8 November 2013 15:38, Catalin Marinas <catalin.marinas@arm.com> wrote:
> > On Thu, Nov 07, 2013 at 06:53:06PM +0000, Ard Biesheuvel wrote:
> [...]
> >> I agree that whether you want to put up with the additional layer of
> >> indirection, additional relocations etc is a matter of taste, but
> >> having writable pointers around that are easily dereferenced directly
> >> by unprivileged users is a bad idea in any case,
> >
> > "unprivileged users"?!
>
> Well, I know this may seem far fetched, but /proc/cpuinfo lacks any
> kind of access control because it is deemed harmless, while, as an
> unprivileged user, having some pointers in .data that you can clobber
> (through some other vulnerability) without breaking anything, and can
> conveniently dereference at your leisure by cat'ing /proc/cpuinfo, may
> well be something that could potentially be used in the wrong way.
That's far fetched indeed ;). I'm pretty sure once you can write the
.data section there are far better way to hack the kernel.
> >> so if this is your preferred solution, it's fine by me.
> >
> > My preferred solution is to leave it as it is ;).
>
> It's a trivial fix, so why not apply it?
So far my toolchain already places it in .rodata since there is no write
to these pointers.
--
Catalin
next prev parent reply other threads:[~2013-11-08 17:19 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-06 16:32 [PATCH trivial] arm64: constify hwcap_str Ard Biesheuvel
2013-11-07 17:50 ` Catalin Marinas
2013-11-07 18:53 ` Ard Biesheuvel
2013-11-08 14:38 ` Catalin Marinas
2013-11-08 17:14 ` Ard Biesheuvel
2013-11-08 17:19 ` Catalin Marinas [this message]
2013-11-08 17:27 ` Ard Biesheuvel
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=20131108171949.GD17212@arm.com \
--to=catalin.marinas@arm.com \
--cc=linux-arm-kernel@lists.infradead.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.