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  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:   Fri, 29 May 2020 21:46:28 +0100
From:   Al Viro <>
To:     Linus Torvalds <>
Cc:     Linux Kernel Mailing List <>,
        linux-fsdevel <>
Subject: Re: [PATCH 2/2] dlmfs: convert dlmfs_file_read() to copy_to_user()

On Thu, May 28, 2020 at 08:42:25PM -0700, Linus Torvalds wrote:

> >         struct sigset_argpack argpack = { NULL, 0 };
> >
> >         if (get_sigset_argpack(sig, &argpack))
> >                 return -EFAULT;
> and now you can use "argpack.sigset" and "argpack.sigset_size".
> No?
> Same exact deal for the compat case, where you'd just need that compat
> struct (using "compat_uptr_t" and "compat_size_t"), and then
> >         struct compat_sigset_argpack argpack = { 0, 0 };
> >
> > +       if (get_compat_sigset_argpack(sig, &argpack))
> > +               return -EFAULT;
> and then you use the result with "compat_ptr(argpack.sigset)" and
> "argpack.sigset_size".
> Or did I mis-read anything and get confused by that code in your patch?

Umm...  I'd been concerned about code generation, but it actually gets
split into a pair of scalars just fine...

Al, trying to resist the temptation to call those struct bad_idea and
struct bad_idea_32...

All jokes aside, when had we (or anybody else, really) _not_ gotten
into trouble when passing structs across the kernel boundary?  Sure,
sometimes you have to (stat, for example), but just look at the amount
of PITA stat() has spawned...

Powered by blists - more mailing lists