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:   Fri, 19 Feb 2021 12:26:21 +0300
From:   Dan Carpenter <dan.carpenter@...cle.com>
To:     David Laight <David.Laight@...LAB.COM>
Cc:     "'Ian Abbott'" <abbotti@....co.uk>,
        Greg KH <gregkh@...uxfoundation.org>,
        Atul Gopinathan <atulgopinathan@...il.com>,
        "devel@...verdev.osuosl.org" <devel@...verdev.osuosl.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] staging: comedi: cast to (unsigned int *)

On Fri, Feb 19, 2021 at 09:03:59AM +0000, David Laight wrote:
> > It's kind of moot anyway because the patch is outdated.  But the reason
> > for the ___force is that the same `struct comedi_cmd` is used in both
> > user and kernel contexts.  In user contexts, the `chanlist` member
> > points to user memory and in kernel contexts it points to kernel memory
> > (copied from userspace).
> 
> Can't you use a union of the user and kernel pointers?
> (Possibly even anonymous?)
> Although, ideally, keeping them in separate fields is better.
> 8 bytes for a pointer isn't going make a fat lot of difference.
> 

Creating a union is worse than adding casts.  With the casts, at least
you know that you're doing something dangerous.  It's good that it looks
scary because it is scary.

Keeping them in separate fields is a good idea, but this is part of the
user space API so it's not possible.

The best we can do is adding some more comments so people know why we
are doing the scary casts.

regards,
dan carpenter

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ