linux-kernel - Re: [PATCH 10/20] signal/vm86_32: Properly send SIGSEGV when the vm86 state cannot be saved.

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:   Thu, 21 Oct 2021 13:33:47 -0700
From:   Kees Cook <keescook@...omium.org>
To:     "Eric W. Biederman" <ebiederm@...ssion.com>
Cc:     linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Oleg Nesterov <oleg@...hat.com>,
        Al Viro <viro@...iv.linux.org.uk>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        x86@...nel.org, H Peter Anvin <hpa@...or.com>
Subject: Re: [PATCH 10/20] signal/vm86_32: Properly send SIGSEGV when the
 vm86 state cannot be saved.

On Thu, Oct 21, 2021 at 12:02:49PM -0500, Eric W. Biederman wrote:
> Kees Cook <keescook@...omium.org> writes:
> 
> > On Wed, Oct 20, 2021 at 12:43:56PM -0500, Eric W. Biederman wrote:
> >> Instead of pretending to send SIGSEGV by calling do_exit(SIGSEGV)
> >> call force_sigsegv(SIGSEGV) to force the process to take a SIGSEGV
> >> and terminate.
> >> 
> >> Update handle_signal to return immediately when save_v86_state fails
> >> and kills the process.  Returning immediately without doing anything
> >> except killing the process with SIGSEGV is also what signal_setup_done
> >> does when setup_rt_frame fails.  Plus it is always ok to return
> >> immediately without delivering a signal to a userspace handler when a
> >> fatal signal has killed the current process.
> >
> > Do the tools/testing/selftests/x86 tests all pass after these changes? I
> > know Andy has a bunch of weird corner cases in there.
> 
> That would require a 32bit userspace wouldn't it?
> 
> It is a good idea so I will see if I can dig such a box up, but I
> unfortunately don't have an up-to-date 32bit box handy, or even
> an up-to-date box with a 32bit userspace.
> 
> It has been about 20 years since I have done much with 32bit x86.

I've done recent ia32 testing just under qemu with a 32bit x86 image.
Since I've got this set up already, I'll give it a spin...

> How hard is it to run the tests under tools/testing/selftests/...
> Last time I tried it was a royal pain.  I am hoping it is better this
> round.

It _is_ a little weird. :P I do it like this, pulled from the larger docs[1]:

# Build host
$ make -C tools/testing/selftests gen_tar TARGETS="x86" FORMAT=.xz
$ scp $(find tools/testing/selftests -name kselftests.tar.xz) target:

# Target host
$ mkdir kselftests && cd kselftests
$ tar -xaf ../kselftests.tar.xz
$ ./run_kselftest.sh


[1] https://www.kernel.org/doc/html/latest/dev-tools/kselftest.html

-- 
Kees Cook