From: nbd@openwrt•org (Felix Fietkau)
To: linux-arm-kernel@lists•infradead.org
Subject: CONFIG_CPU_SW_DOMAIN_PAN breakage on ARM11 MPCore
Date: Wed, 20 Jan 2016 21:06:01 +0100 [thread overview]
Message-ID: <569FE8A9.4080700@openwrt.org> (raw)
In-Reply-To: <20160120195722.GU19062@n2100.arm.linux.org.uk>
On 2016-01-20 20:57, Russell King - ARM Linux wrote:
> On Tue, Jan 19, 2016 at 04:23:28PM +0000, Russell King - ARM Linux wrote:
>> However, the SMP vs UP mode thing does have an effect on the fix
>> too - if we have MPcore systems operating in UP mode, we're going
>> to need a much more complex and hideous fix - we're likely going
>> to need to out-of-line _all_ the TLB flushing which is going to
>> be nasty for the vast majority not affected by this. :(
>
> Having thought about this some more, I'm coming to the conclusion that
> the only sane solution here is to change the help text for SW_PAN such
> that if you want to run a kernel on ARM11 MPcore, you must disable
> SW_PAN.
>
> Unless that approach is taken, we're into a rewrite the ARM TLB flushing
> (as mentioned above) and I really don't want to do that just for the
> sake of one relatively rare early SMP CPU.
>
> For those who think we can simply apply my patch, consider the CNS3xxx
> situation, which is not a SMP system in mainline kernels, but uses ARM11
> MPcore CPUs (and thus fails when SMP is disabled, even with my patch.)
>
> So I'm going to suggest that this option's help text is changed to:
>
> config CPU_SW_DOMAIN_PAN
> bool "Enable use of CPU domains to implement privileged no-access"
> depends on MMU && !ARM_LPAE
> default y
> help
> Increase kernel security by ensuring that normal kernel accesses
> are unable to access userspace addresses. This can help prevent
> use-after-free bugs becoming an exploitable privilege escalation
> by ensuring that magic values (such as LIST_POISON) will always
> fault when dereferenced.
>
> Note: This option is incompatible with ARM11 MPcore and must not
> be used with kernels which are to run on this CPU, whether in SMP
> or UP mode.
>
> CPUs with low-vector mappings use a best-efforts implementation.
> Their lower 1MB needs to remain accessible for the vectors, but
> the remainder of userspace will become appropriately inaccessible.
>
> Unfortunately, that's still going to lead to people hitting this, and
> possibly wasting a long time debugging it needlessly - but I don't
> have any better solution for this.
We should at least add a dependency to disable this when support for a
known ARM11 MPCore platform is selected. Maybe add a CPU_MPCORE bool for
this.
- Felix
next prev parent reply other threads:[~2016-01-20 20:06 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-18 23:14 CONFIG_CPU_SW_DOMAIN_PAN breakage on ARM11 MPCore Felix Fietkau
2016-01-19 9:38 ` Russell King - ARM Linux
2016-01-19 9:53 ` Felix Fietkau
2016-01-19 15:27 ` Arnd Bergmann
2016-01-19 15:38 ` Felix Fietkau
2016-01-19 16:23 ` Russell King - ARM Linux
2016-01-20 19:57 ` Russell King - ARM Linux
2016-01-20 20:06 ` Felix Fietkau [this message]
2016-01-20 20:31 ` Arnd Bergmann
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=569FE8A9.4080700@openwrt.org \
--to=nbd@openwrt$(echo .)org \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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