linux-kernel - Re: [PATCH v9 1/1] ptrace,syscall_user_dispatch: checkpoint/restore support for SUD

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: <Y+rPH0T5r38+l2gB@memverge.com>
Date:   Mon, 13 Feb 2023 19:00:31 -0500
From:   Gregory Price <gregory.price@...verge.com>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     Gregory Price <gourry.memverge@...il.com>,
        linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org,
        oleg@...hat.com, avagin@...il.com, peterz@...radead.org,
        luto@...nel.org, krisman@...labora.com, corbet@....net,
        shuah@...nel.org
Subject: Re: [PATCH v9 1/1] ptrace,syscall_user_dispatch: checkpoint/restore
 support for SUD

On Mon, Feb 13, 2023 at 09:26:21PM +0100, Thomas Gleixner wrote:
> On Fri, Feb 10 2023 at 02:25, Gregory Price wrote:
> > +struct ptrace_sud_config {
> > +	__u64 mode;
> > +	__s8 *selector;
> 
> How is this correct for a 32bit ptracer running on a 64bit kernel? Aside
> of not wiring up the compat syscall without any argumentation in the
> changelog.
> 

I'm having a little trouble wrapping my head around what is "right" here
with regard to compat.  Granted I've never had to deal with compat
issues, so please excuse the ignorance if this is a trivial issue.

PEEKSIGINFO has a similar u64 field for an argument, and likewise does
not have plumbing through the compat path (it falls through to
ptrace_request).

There is no compat counterpart to this peeksiginfo structure, and
therefore no compat plumbing.  

struct ptrace_peeksiginfo_args {
        __u64 off;      /* from which siginfo to start */
        __u32 flags;
        __s32 nr;       /* how may siginfos to take */
};

static int ptrace_peek_siginfo(struct task_struct *child,
                               unsigned long addr,
                               unsigned long data)
{
        struct ptrace_peeksiginfo_args arg;
[...snip...]
        ret = copy_from_user(&arg, (void __user *) addr,
                                sizeof(struct ptrace_peeksiginfo_args));
[...snip...]
}

This makes it appear that the args struct has a __u64 field regardless
of mode. Either this or anything compiling in 32-bit mode will run into
an issue with any of these __u64 structures.  That doesn't seem likely.

This code suggests there's no need for special compat code. Otherwise,
is this a bug?  Too much data would be copied from userland if the field
is truncated to 32-bit when compiled.

either way, would an appropriate compat structure be:

struct compat_ptrace_sud_config {
    __u32 mode;
    __s8 *selector;
    __u32 offset_high;
    __u32 offset_low;
    __u32 len_high;
    __u32 len_low;
};

Or is a 32-bit program attempting to ptrace a 64-bit program not
generally expected to be supported? (from a bit of research, seems
like "you can make the attempt, good luck", levels of supported).

Thanks again for your time,
~Gregory