From: Gabriel Paubert <paubert@iram.es>
To: Adrian Cox <adrian@humboldt.co.uk>
Cc: Tom Rini <trini@kernel.crashing.org>, linuxppc-dev@lists.linuxppc.org
Subject: Re: New 745x errata
Date: Mon, 17 Nov 2003 18:05:14 +0100 [thread overview]
Message-ID: <20031117170514.GA32760@iram.es> (raw)
In-Reply-To: <1069083421.10537.63.camel@newt>
On Mon, Nov 17, 2003 at 03:37:00PM +0000, Adrian Cox wrote:
> On Mon, 2003-11-17 at 15:12, Gabriel Paubert wrote:
> > On Mon, Nov 17, 2003 at 02:57:53PM +0000, Adrian Cox wrote:
> > > Any opinion on the dcbt issue? It looks like it could provide a way for
> > > a malicious userspace application to crash the machine, though it needs
> > > a combination of:
> > > 1) good timing
> > > 2) a peripheral that would be confused by an extra read cycle
>
> > Well, only privileged applications should have access to
> > peripherals, no?
> [...]
> > But maybe I miss something.
>
> That's the bug - a dcbt to a protected region can cause a spurious read
> cycle to that address. To trigger it:
>
> 1) the target address is in a BAT or TLB, marked as supervisor access
> only.
> 2) a cache miss to a cache alias of the target address reaches the
> load-store unit
> 2) you issue a dcbt to the target address within 1 clock cycle of step
> 2.
>
> Actually, I now believe the bug may be harmless, as the peripheral has
> an extra defence - its BAT or TLB entry will be non-cacheable, so no bus
> cycle will occur. The text of the errata doesn't spell this out as
> clearly as I'd like, but I think all it can do is cause a spurious bus
> cycle to ram.
Now that I downloaded the errata, it is rather clear that if the area
is cache-inhibited, there won't be any spurious access.
You might have a spurious access to a write-through area, even if
guarded it seems, but if something is marked write through, spurious
reads should have no side effects to start with.
In short, I believe that the erratum is harmless, until somebody
clearly shows that I'm wrong of course :-)
Gabriel
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2003-11-17 17:05 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-11-13 11:05 New 745x errata Adrian Cox
2003-11-14 10:40 ` Giuliano Pochini
2003-11-14 11:00 ` Adrian Cox
2003-11-14 16:24 ` Tom Rini
2003-11-17 14:57 ` Adrian Cox
2003-11-17 15:04 ` Tom Rini
2003-11-17 15:34 ` Adrian Cox
2003-11-18 8:40 ` Giuliano Pochini
2003-11-17 15:12 ` Gabriel Paubert
2003-11-17 15:37 ` Adrian Cox
2003-11-17 15:49 ` Gabriel Paubert
2003-11-17 17:05 ` Gabriel Paubert [this message]
2003-11-17 17:34 ` Jon Masters
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=20031117170514.GA32760@iram.es \
--to=paubert@iram.es \
--cc=adrian@humboldt.co.uk \
--cc=linuxppc-dev@lists.linuxppc.org \
--cc=trini@kernel.crashing.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.