[PATCH] x86: Improve description of IA32_EMULATION_DEFAULT_DISABLED

[PATCH] x86: Improve description of IA32_EMULATION_DEFAULT_DISABLED

[Hanno Böck]

The description of the option disables a default, but does not mention
how to change that default. To make it easier to find out, mention boot
parameter ia32_emulation.

Signed-off-by: Hanno Böck <hanno@hboeck.de>
---

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 5edec175b..a65ff33e0 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -3006,8 +3006,10 @@ config IA32_EMULATION_DEFAULT_DISABLED
 	depends on IA32_EMULATION
 	help
 	  Make IA32 emulation disabled by default. This prevents loading 32-bit
-	  processes and access to 32-bit syscalls. If unsure, leave it to its
-	  default value.
+	  processes and access to 32-bit syscalls. If set, IA32 emulation can be
+	  re-enabled with the boot parameter ia32_emulation=true.
+
+	  If unsure, leave it to its default value.
 
 config X86_X32_ABI
 	bool "x32 ABI for 64-bit mode"

Re: [PATCH] x86: Improve description of IA32_EMULATION_DEFAULT_DISABLED

[Borislav Petkov]

On Tue, Jan 30, 2024 at 10:45:43AM +0100, Hanno Böck wrote:
> The description of the option disables a default, but does not mention
> how to change that default. To make it easier to find out, mention boot
> parameter ia32_emulation.
> 
> Signed-off-by: Hanno Böck <hanno@hboeck.de>
> ---
> 
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 5edec175b..a65ff33e0 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -3006,8 +3006,10 @@ config IA32_EMULATION_DEFAULT_DISABLED
>  	depends on IA32_EMULATION
>  	help
>  	  Make IA32 emulation disabled by default. This prevents loading 32-bit
> -	  processes and access to 32-bit syscalls. If unsure, leave it to its
> -	  default value.
> +	  processes and access to 32-bit syscalls. If set, IA32 emulation can be
> +	  re-enabled with the boot parameter ia32_emulation=true.

That sentence should say one can enable it *dynamically* with the cmdline
param.

But this text reads weird: if I want to enable it, then I won't set
IA32_EMULATION_DEFAULT_DISABLED in the first place and I won't have that
problem.

So the use case must be something along the lines of, ia32 emu is
default-disabled at build time but for certain cases where one wants it,
one can still enable it per-boot with a cmdline param.

So what's the story here?

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: [PATCH] x86: Improve description of IA32_EMULATION_DEFAULT_DISABLED

[Nikolay Borisov]

On 6.02.24 г. 16:58 ч., Borislav Petkov wrote:
> On Tue, Jan 30, 2024 at 10:45:43AM +0100, Hanno Böck wrote:
>> The description of the option disables a default, but does not mention
>> how to change that default. To make it easier to find out, mention boot
>> parameter ia32_emulation.
>>
>> Signed-off-by: Hanno Böck <hanno@hboeck.de>
>> ---
>>
>> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>> index 5edec175b..a65ff33e0 100644
>> --- a/arch/x86/Kconfig
>> +++ b/arch/x86/Kconfig
>> @@ -3006,8 +3006,10 @@ config IA32_EMULATION_DEFAULT_DISABLED
>>   	depends on IA32_EMULATION
>>   	help
>>   	  Make IA32 emulation disabled by default. This prevents loading 32-bit
>> -	  processes and access to 32-bit syscalls. If unsure, leave it to its
>> -	  default value.
>> +	  processes and access to 32-bit syscalls. If set, IA32 emulation can be
>> +	  re-enabled with the boot parameter ia32_emulation=true.
> 
> That sentence should say one can enable it *dynamically* with the cmdline
> param.
> 
> But this text reads weird: if I want to enable it, then I won't set
> IA32_EMULATION_DEFAULT_DISABLED in the first place and I won't have that
> problem.
> 
> So the use case must be something along the lines of, ia32 emu is
> default-disabled at build time but for certain cases where one wants it,
> one can still enable it per-boot with a cmdline param.
> 
> So what's the story here?

The use case is if a distribution wants to disable ia32 emu by default 
but at the same time wants to give users the ability to override it. 
Which is pretty much the use case you presented.

> 
> Thx.
>