linux-kernel - Re: [PATCH v7 0/3] Fix dosemu vm86() fault

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 for Android: free password hash cracker in your pocket

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

Message-ID: <bd933e11-7836-462f-9b6b-5172301f188b@leemhuis.info>
Date: Tue, 8 Oct 2024 15:52:10 +0200
From: Thorsten Leemhuis <regressions@...mhuis.info>
To: Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>,
 Borislav Petkov <bp@...en8.de>, Dave Hansen <dave.hansen@...ux.intel.com>
Cc: linux-kernel@...r.kernel.org, x86@...nel.org,
 Robert Gill <rtgill82@...il.com>, Jari Ruusu <jariruusu@...tonmail.com>,
 Brian Gerst <brgerst@...il.com>, antonio.gomez.iglesias@...ux.intel.com,
 daniel.sneddon@...ux.intel.com, stable@...r.kernel.org,
 Linux kernel regressions list <regressions@...ts.linux.dev>
Subject: Re: [PATCH v7 0/3] Fix dosemu vm86() fault

Hi, Thorsten here, the Linux kernel's regression tracker. Top-posting
for once, to make this easily accessible to everyone.

Is there hope that patches like these makes it to mainline any time
soon? I fully understand that this it a hard problem, but in the end
what triggered this were at least two regression reports afaics:
https://bugzilla.kernel.org/show_bug.cgi?id=218707
https://lore.kernel.org/lkml/IdYcxU6x6xuUqUg8cliJUnucfwfTO29TrKIlLGCCYbbIr1EQnP0ZAtTxdAM2hp5e5Gny_acIN3OFDS6v0sazocnZZ1UBaINEJ0HoDnbasSI=@protonmail.com/

Sure, the older one was in April, so one week more or less now won't
make much of a difference. But I think it still would be great to get
this fixed rather sooner than later. Or where those issues meanwhile
fixed through other patches without me noticing and I'm making a fool of
myself here?

This yet again makes me wonder if some "[regression fix]" in the subject
or "CC: regressions@...ts.linux.dev" in the patches would help to make
the regression aspect obvious to everyone involved. But it would create
yet another small bit of overhead... :-/

Pawan Gupta, btw: many thx for working on this and sticking to it!

Ciao, Thorsten

On 26.09.24 00:25, Pawan Gupta wrote:
> Changes in v7:
> - Using %ss for verw fails kselftest ldt_gdt.c in 32-bit mode, use safer %cs instead (Dave).
> 
> v6: https://lore.kernel.org/r/20240905-fix-dosemu-vm86-v6-0-7aff8e53cbbf@linux.intel.com
> - Use %ss in 64-bit mode as well for all VERW calls. This avoids any having
>   a separate macro for 32-bit (Dave).
> - Split 32-bit mode fixes into separate patches.
> 
> v5: https://lore.kernel.org/r/20240711-fix-dosemu-vm86-v5-1-e87dcd7368aa@linux.intel.com
> - Simplify the use of ALTERNATIVE construct (Uros/Jiri/Peter).
> 
> v4: https://lore.kernel.org/r/20240710-fix-dosemu-vm86-v4-1-aa6464e1de6f@linux.intel.com
> - Further simplify the patch by using %ss for all VERW calls in 32-bit mode (Brian).
> - In NMI exit path move VERW after RESTORE_ALL_NMI that touches GPRs (Dave).
> 
> v3: https://lore.kernel.org/r/20240701-fix-dosemu-vm86-v3-1-b1969532c75a@linux.intel.com
> - Simplify CLEAR_CPU_BUFFERS_SAFE by using %ss instead of %ds (Brian).
> - Do verw before popf in SYSEXIT path (Jari).
> 
> v2: https://lore.kernel.org/r/20240627-fix-dosemu-vm86-v2-1-d5579f698e77@linux.intel.com
> - Safe guard against any other system calls like vm86() that might change %ds (Dave).
> 
> v1: https://lore.kernel.org/r/20240426-fix-dosemu-vm86-v1-1-88c826a3f378@linux.intel.com
> 
> Hi,
> 
> This series fixes a #GP in 32-bit kernels when executing vm86() system call
> in dosemu software. In 32-bit mode, their are cases when user can set an
> arbitrary %ds that can cause a #GP when executing VERW instruction. The
> fix is to use %ss for referencing the VERW operand.
> 
> Patch 1-2: Fixes the VERW callsites in 32-bit entry path.
> Patch   3: Uses %ss for VERW in 32-bit and 64-bit mode.
> 
> The fix is tested with below kselftest on 32-bit kernel:
> 
> 	./tools/testing/selftests/x86/entry_from_vm86.c
> 
> 64-bit kernel was boot tested. On a Rocket Lake, measuring the CPU cycles
> for VERW with and without the %ss shows no significant difference. This
> indicates that the scrubbing behavior of VERW is intact.
> 
> Thanks,
> Pawan
> 
> Signed-off-by: Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>
> ---
> Pawan Gupta (3):
>       x86/entry_32: Do not clobber user EFLAGS.ZF
>       x86/entry_32: Clear CPU buffers after register restore in NMI return
>       x86/bugs: Use code segment selector for VERW operand
> 
>  arch/x86/entry/entry_32.S            | 6 ++++--
>  arch/x86/include/asm/nospec-branch.h | 6 ++++--
>  2 files changed, 8 insertions(+), 4 deletions(-)
> ---
> base-commit: 431c1646e1f86b949fa3685efc50b660a364c2b6
> change-id: 20240426-fix-dosemu-vm86-dd111a01737e
> 
> Best regards,

#regzbot poke