linux-kernel - Re: [PATCH] drm/xe/vsec: enforce CONFIG_INTEL

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <fjforguil5lcij77tgmjk5sw5bzuwg7m34nsdmrzbinnmt2xte@moz3kbsg6tgi>
Date: Tue, 17 Dec 2024 14:14:00 -0600
From: Lucas De Marchi <lucas.demarchi@...el.com>
To: Arnd Bergmann <arnd@...db.de>
Cc: Rodrigo Vivi <rodrigo.vivi@...el.com>, Arnd Bergmann <arnd@...nel.org>, 
	michael.j.ruhl@...el.com, 
	Thomas Hellström <thomas.hellstrom@...ux.intel.com>, Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>, 
	Maxime Ripard <mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>, 
	Dave Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>, 
	"David E. Box" <david.e.box@...ux.intel.com>, Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>, 
	Andy Shevchenko <andriy.shevchenko@...ux.intel.com>, Jani Nikula <jani.nikula@...el.com>, 
	Geert Uytterhoeven <geert+renesas@...der.be>, Tejas Upadhyay <tejas.upadhyay@...el.com>, 
	Hans de Goede <hdegoede@...hat.com>, intel-xe@...ts.freedesktop.org, dri-devel@...ts.freedesktop.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] drm/xe/vsec: enforce CONFIG_INTEL_VSEC dependency

On Tue, Dec 17, 2024 at 08:28:59PM +0100, Arnd Bergmann wrote:
>On Tue, Dec 17, 2024, at 19:52, Rodrigo Vivi wrote:
>> On Tue, Dec 17, 2024 at 08:18:44AM +0100, Arnd Bergmann wrote:
>>> From: Arnd Bergmann <arnd@...db.de>
>>>
>>> When INTEL_VSEC is in a loadable module, XE cannot be built-in any more:
>>>
>>> x86_64-linux-ld: vmlinux.o: in function `xe_vsec_init':
>>> (.text+0x19861bf): undefined reference to `intel_vsec_register'
>>>
>>> This could be enforced using a 'depends on INTEL_VSEC || !INTEL_VSEC'
>>> style dependency to allow building with VSEC completely disabled.
>>> My impression here is that this was not actually intended, and that
>>> continuing to support that combination would lead to more build bugs.

why? if xe is built-in, vsec needs to be built-in as well. If xe is a
module, vsec can be either built-in or a module.

>>>
>>> Instead, make it a hard dependency as all other INTEL_VSEC users are,
>>> and remove the inline stub alternative. This leads to a dependency
>>> on CONFIG_X86_PLATFORM_DEVICES, so the 'select' has to be removed
>>> to avoid a circular dependency.
>>>
>>
>> I really don't want us to hard lock this X86 dependency here.
>> What if we add a new DRM_XE_DGFX_PMT_SUPPORT and that
>> depends on INTEL_VSEC ?
>
>Yes, that should work if it gets phrased correctly.
>Something like
>
>config DRM_XE_DGFX_PMT_SUPPORT
>       bool "X86 PMT support"
>       depends on DRM_XE && INTEL_VSEC
>       depends on DRM_XE=m || INTEL_VSEC=y
>       depends on X86 || COMPILE_TEST


that looks good to me.

thanks
Lucas De Marchi