[drm] [radeon] [3.1.4] slub memory corruption in drm_vblank_cleanup
Alex Deucher
alexdeucher at gmail.com
Wed Dec 14 10:14:25 PST 2011
On Wed, Dec 14, 2011 at 12:49 PM, batouzo <batouzo at gmx.com> wrote:
> On 12/14/2011 06:40 PM, Alex Deucher wrote:
>> On Wed, Dec 14, 2011 at 12:27 PM, batouzo <batouzo at 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?
I don't want to get into a philosophical discussion about firmware.
It's required for proper operation on radeon cards. Not using it will
disable acceleration and interrupts and is overall not well
tested/supported. On newer asics that require the MC ucode, the MC
ucode is required to use the card at all as the boot up state is only
enough to light up the screen.
Alex
More information about the dri-devel
mailing list