linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
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/

  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 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).