CONFIG_DRM_LEGACY

CONFIG_DRM_LEGACY

[Peter Müller]

[-- Attachment #1: Type: text/plain, Size: 1032 bytes --]

Hello development folks,

recently, it has been flagged to me that we ship our kernels with CONFIG_DRM_LEGACY enabled.

The documentation to this reads:

> Enable legacy DRI1 drivers. Those drivers expose unsafe and dangerous
> APIs to user-space, which can be used to circumvent access
> restrictions and other security measures. For backwards compatibility
> those drivers are still available, but their use is highly
> inadvisable and might harm your system.
> 
> You are recommended to use the safe modeset-only drivers instead, and
> perform 3D emulation in user-space.
> 
> Unless you have strong reasons to go rogue, say "N".

Because of the kernel released on July 7 and its fixes to ASIX USB-to-Ethernet adapters, I
am currently working on that sector of IPFire 2.x anyway. Unless somebody of you can recall
why we really need to have CONFIG_DRM_LEGACY enabled, I would submit a patch disabling it -
its documentation does not inspire confidence at all. :-)

Thanks, and best regards,
Peter Müller

Re: CONFIG_DRM_LEGACY

[Adolf Belka]

[-- Attachment #1: Type: text/plain, Size: 1987 bytes --]

Hi Peter,

On 10/07/2022 12:00, Peter Müller wrote:
> Hello development folks,
>
> recently, it has been flagged to me that we ship our kernels with CONFIG_DRM_LEGACY enabled.

Looking through Arch Linux I see that since Kernel 5.14 this option has been present. Some OS's have it enabled and some have it disabled. Arch Linux is in the disabled camp and they had already removed many of the DRM based drivers from their core repository.

The result of that is that anyone needing to use old DRM based video cards such as Nvidia 340 and Mach64DRM have to now build the video driver themselves  but also build their own kernel to set this parameter.

> The documentation to this reads:
>
>> Enable legacy DRI1 drivers. Those drivers expose unsafe and dangerous
>> APIs to user-space, which can be used to circumvent access
>> restrictions and other security measures. For backwards compatibility
>> those drivers are still available, but their use is highly
>> inadvisable and might harm your system.
>>
>> You are recommended to use the safe modeset-only drivers instead, and
>> perform 3D emulation in user-space.
>>
>> Unless you have strong reasons to go rogue, say "N".
> Because of the kernel released on July 7 and its fixes to ASIX USB-to-Ethernet adapters, I
> am currently working on that sector of IPFire 2.x anyway. Unless somebody of you can recall
> why we really need to have CONFIG_DRM_LEGACY enabled, I would submit a patch disabling it -
> its documentation does not inspire confidence at all. :-)

I had a similar feeling when I read about it.

I would suppose the question would be how many of the IPFire users use older DRM based video cards on their IPFire machines.

Does IPFire include the drivers for these DRM based video cards? If not then making the config disabled shouldn't give any problem.

That's my input from having a quick search on this topic.

Regards,

Adolf.

> Thanks, and best regards,
> Peter Müller

Re: CONFIG_DRM_LEGACY

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 2561 bytes --]

Hello,

> On 10 Jul 2022, at 13:12, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
> 
> Hi Peter,
> 
> On 10/07/2022 12:00, Peter Müller wrote:
>> Hello development folks,
>> 
>> recently, it has been flagged to me that we ship our kernels with CONFIG_DRM_LEGACY enabled.
> 
> Looking through Arch Linux I see that since Kernel 5.14 this option has been present. Some OS's have it enabled and some have it disabled. Arch Linux is in the disabled camp and they had already removed many of the DRM based drivers from their core repository.
> 
> The result of that is that anyone needing to use old DRM based video cards such as Nvidia 340 and Mach64DRM have to now build the video driver themselves  but also build their own kernel to set this parameter.
> 
>> The documentation to this reads:
>> 
>>> Enable legacy DRI1 drivers. Those drivers expose unsafe and dangerous
>>> APIs to user-space, which can be used to circumvent access
>>> restrictions and other security measures. For backwards compatibility
>>> those drivers are still available, but their use is highly
>>> inadvisable and might harm your system.
>>> 
>>> You are recommended to use the safe modeset-only drivers instead, and
>>> perform 3D emulation in user-space.
>>> 
>>> Unless you have strong reasons to go rogue, say "N".
>> Because of the kernel released on July 7 and its fixes to ASIX USB-to-Ethernet adapters, I
>> am currently working on that sector of IPFire 2.x anyway. Unless somebody of you can recall
>> why we really need to have CONFIG_DRM_LEGACY enabled, I would submit a patch disabling it -
>> its documentation does not inspire confidence at all. :-)
> 
> I had a similar feeling when I read about it.
> 
> I would suppose the question would be how many of the IPFire users use older DRM based video cards on their IPFire machines.
> 
> Does IPFire include the drivers for these DRM based video cards? If not then making the config disabled shouldn't give any problem.

Currently nobody is using any card with DRM. We have all modules blacklisted in favour of framebuffer.

I would prefer to change that, use DRM, and drop framebuffer.

Since we do not need to support all those DRM features and all cards and because all cards should support come VESA-compatibility mode, this should be safe to be disabled.

I suppose Arne is the best person to comment on this.

-Michael

> 
> That's my input from having a quick search on this topic.
> 
> Regards,
> 
> Adolf.
> 
>> Thanks, and best regards,
>> Peter Müller