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]
Date:   Tue, 13 Dec 2022 01:04:32 +0500
From:   stsp <stsp2@...dex.ru>
To:     "Eric W. Biederman" <ebiederm@...ssion.com>
Cc:     linux-kernel@...r.kernel.org, linux-x86_64@...r.kernel.org,
        luto@...nel.org, Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
        "H. Peter Anvin" <hpa@...or.com>, Al Viro <viro@...IV.linux.org.uk>
Subject: Re: strange behavior with sigreturn() to 32bit

Hi Eric,

13.12.2022 00:36, Eric W. Biederman пишет:
> Stas,
>
> in your github report you mention that you believe this is a regression
> https://github.com/dosemu2/dosemu2/pull/1830.
>
> Can you tell us the last kernel this worked on?

The only thing I actually think is a
regression, is the return of 0 as an error
code for GPF. I am pretty sure it used
to work, because I was reporting the
zeroed-out err code to @amluto and
he fixed it. But that was something like
5 years ago. These days @amluto seems
to be inactive, does anyone know what
have happened? He was always providing
a very quick help in the past (and well,
he wrote all that 64-32 switching code
in sigreturn for us).
Other problems I've found, are likely not
a regressions. I.e. I never tried such
tests under gdb before and I never tried
to set high dword of RIP to non-zero.
In fact, reliable err code is what I care
most. If things can't be fixed under gdb
or if I should always clear high part of
RIP before switching to 32bit segment -
fine. But zero error code is bad.


>    Which kernel you tested
> that this fails on?

5.19.0-26-generic from ubuntu.


>    It would be awesome if you could bisect this to the
> commit that is broken but at least knowing kernel's you have tried that
> work and don't work would be very useful.

Perhaps I'll look into setting up the test
env under qemu if everything else fails.

> Dosemu is old enough that anything it has down historically that no
> longer works certainly counts as a regression and should be fixed.
dosemu2 nowadays is using Andy's sigreturn
new code, which is now about 10 years old.
Historic dosemu afaik is not using anything
like that, switching to 32bit by hands with iret.

Powered by blists - more mailing lists