linux-kernel - Re: System Call trashing registers

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: <CA+jjjYTcKyuy6HdwPsXr99FvHMK8vhmU8sqhZLE0m2n__GaRpA@mail.gmail.com>
Date:   Mon, 28 Aug 2023 10:11:55 -0700
From:   Joshua Hudson <joshudson@...il.com>
To:     David Laight <David.Laight@...lab.com>
Cc:     linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: System Call trashing registers

On Mon, Aug 28, 2023 at 10:06 AM David Laight <David.Laight@...lab.com> wrote:
>
> From: Joshua Hudson
> > Sent: 24 August 2023 17:15
> >
> > 1) A lot of my old 32-bit programs don't work on x64 linux anymore
> > because int 80h now trashes ecx and edx. This hasn't been a serious
> > problem for me.
>
> Aren't both ecx and edx caller saved?
> So if the code is using asm syscall wrappers provided the asm
> wrappers don't expect the registers be saved (which is unlikely)
> then it is safe for the kernel to trash them.
>
> OTOH I have seen code compiled with inlined syscall code
> (but not recently). In that case it will matter.
>
> It gets more interesting with all the xmm/ymm/zmm registers.
> They are also all caller saved, so if the compiler always
> sees a real function call wrapping a system call then the kernel
> need not save them and can return with them all set to zero.
>
> I don't believe that is done, but it is likely to be a measurable
> performance gain for most programs.
>
>         David
>
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
> Registration No: 1397386 (Wales)

The actual question is "why isn't trashing the registers with arbitrary values
from the kernel stack" a security vulnerability? It doesn't look like
they're being
set to zero.

It was in fact once documented that all registers are preserved except eax.
(Fun fact: this used to be true across a successful exec(); you could actually
pass extra values to a child exec process in esi and edi until this was
deliberately changed to zero all registers on program entry.)