From: Paul Cercueil <paul@crapouillou.net>
To: Paul Burton <paul.burton@mips.com>
Cc: Ralf Baechle <ralf@linux-mips.org>,
James Hogan <jhogan@kernel.org>,
linux-mips@vger.kernel.org, linux-kernel@vger.kernel.org,
od@zcrc.me
Subject: Re: [PATCH] MIPS: Add support for partial kernel mode on Xburst CPUs
Date: Thu, 25 Jul 2019 16:42:11 -0400 [thread overview]
Message-ID: <1564087331.1848.1@crapouillou.net> (raw)
In-Reply-To: <20190725165930.yvlvmavcgqocl3nn@pburton-laptop>
Le jeu. 25 juil. 2019 à 12:59, Paul Burton <paul.burton@mips.com> a
écrit :
> Hi Paul,
>
> On Wed, Jul 24, 2019 at 07:46:54PM -0400, Paul Cercueil wrote:
>> Support partial kernel mode of Xburst CPUs found in Ingenic SoCs.
>> Partial kernel mode means the userspace applications have access to
>> the TCSM0 banks of the VPU,
>
> So far so (reasonably) good :)
>
>> and can execute cache instructions.
>
> Aaaah! Scary!
>
> Does this allow *all* cache instructions? If so that's a big security
> &
> stability hole - if userland can invalidate kernel data or data from
> other programs then it can create all sorts of chaos.
It looked a bit fishy to me as well, but I couldn't point a finger to
the exact problem. I don't exactly know what it allows and what it
doesn't.
> Also do you know which Ingenic SoCs this is available on? I see it
> documented in the JZ4780 Programming Manual, but Config7 bit 6 is
> shown
> as reserved in my copy of the XBurst1 CPU Core Programming Manual.
I have no idea. I assume all SoCs with a VPU. I know the JZ4770 has it.
> I notice the JZ4780 documentation says it allows access "including
> TCSM,
> CACHE instructions" which is scary too since it doesn't say that's
> *all*
> it allows access to. Though just cache instructions by themselves are
> enough to be game over for any notion of security as mentioned above.
>
> What is it you want to do with this? I'm wondering if we could achieve
> your goal is in a safer way.
The plan was to be able to communicate with the firmware running on the
VPU without going through expensive context switches all the time.
I guess we could mmap() the TCSM memories, but we'd need to bypass the
data cache (is there a flag for that?).
> Thanks,
> Paul
prev parent reply other threads:[~2019-07-25 20:42 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-24 23:46 [PATCH] MIPS: Add support for partial kernel mode on Xburst CPUs Paul Cercueil
2019-07-25 16:59 ` Paul Burton
2019-07-25 20:42 ` Paul Cercueil [this message]
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=1564087331.1848.1@crapouillou.net \
--to=paul@crapouillou.net \
--cc=jhogan@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=od@zcrc.me \
--cc=paul.burton@mips.com \
--cc=ralf@linux-mips.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 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).