All of lore.kernel.org
 help / color / mirror / Atom feed
From: batouzo <batouzo@gmx.com>
To: dri-devel@lists.freedesktop.org
Subject: Re: [drm] [radeon] [3.1.4] slub memory corruption in drm_vblank_cleanup
Date: Wed, 14 Dec 2011 18:49:03 +0100	[thread overview]
Message-ID: <jcanif$lbq$1@dough.gmane.org> (raw)
In-Reply-To: <CADnq5_O5hdw5WBEksuWXfeO1V7JK2-6C1oxbeR+j4tLH_9CihA@mail.gmail.com>

On 12/14/2011 06:40 PM, Alex Deucher wrote:
> On Wed, Dec 14, 2011 at 12:27 PM, batouzo <batouzo@gmx.com> wrote:

> AMD develops and releases the ucode images.  No source is available.
> 
>>
>> This means that entire firmeware of GFX card is flashed on bootup?
>> Btw this is a form of virus protection you could say (or anyway such
>> firmware is volatile and lost on reboot?)
> 
> The ucode is volatile and is lost on reboot.  The different ucode
> images are used for different things.  The PFP and ME ucode images
> provide the acceleration API and the RLC ucode is required to make the
> interrupt controller work.  On newer asics, the MC ucode is used for
> the gddr5 controller on the chip and is required to link train the
> memory so it will run at full speed.

Thanks for explanation.

I hoped using radeon and KMS I'm choosing the "good" (secure / FOSS
philosophy etc) solution, but it seems to not be the case then.

What should one do to have 100% opensource, maximally secure X on radeon
cards?
Maybe I should disable firmware to achieve this goal at cost of
performance - or may disabling firmware actually introduce any
security/stability problems?

Would Intel build-in card be better for this use? Any particular family?

  reply	other threads:[~2011-12-14 17:49 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-13 21:26 [drm] [radeon] [3.1.4] slub memory corruption in drm_vblank_cleanup batouzo
2011-12-13 23:31 ` Jerome Glisse
2011-12-13 23:33   ` batouzo
2011-12-13 23:46     ` Jerome Glisse
2011-12-13 23:47       ` Jerome Glisse
2011-12-14  7:00         ` batouzo
2011-12-14 14:10           ` Alex Deucher
2011-12-14 16:32             ` batouzo
2011-12-14 16:40               ` Alex Deucher
2011-12-14 17:12                 ` batouzo
2011-12-14 17:21                   ` Alex Deucher
2011-12-14 17:27                     ` batouzo
2011-12-14 17:40                       ` Alex Deucher
2011-12-14 17:49                         ` batouzo [this message]
2011-12-14 18:14                           ` Alex Deucher
2011-12-14 16:18           ` Jerome Glisse

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='jcanif$lbq$1@dough.gmane.org' \
    --to=batouzo@gmx.com \
    --cc=dri-devel@lists.freedesktop.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.