linux-kernel - Re: [PATCH 3/3] serial: Add kserial_rs485 to avoid wasted space due to .padding

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:   Mon, 29 Aug 2022 15:09:09 +0300 (EEST)
From:   Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
To:     Andy Shevchenko <andy.shevchenko@...il.com>
cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jiri Slaby <jirislaby@...nel.org>,
        "open list:SERIAL DRIVERS" <linux-serial@...r.kernel.org>,
        Jonathan Corbet <corbet@....net>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Vladimir Zapolskiy <vz@...ia.com>,
        Russell King <linux@...linux.org.uk>,
        Richard Genoud <richard.genoud@...il.com>,
        Nicolas Ferre <nicolas.ferre@...rochip.com>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        Claudiu Beznea <claudiu.beznea@...rochip.com>,
        Shawn Guo <shawnguo@...nel.org>,
        Sascha Hauer <s.hauer@...gutronix.de>,
        Pengutronix Kernel Team <kernel@...gutronix.de>,
        Fabio Estevam <festevam@...il.com>,
        NXP Linux Team <linux-imx@....com>,
        Maxime Coquelin <mcoquelin.stm32@...il.com>,
        Alexandre Torgue <alexandre.torgue@...s.st.com>,
        Linux Documentation List <linux-doc@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-arm Mailing List <linux-arm-kernel@...ts.infradead.org>,
        linux-stm32@...md-mailman.stormreply.com,
        Lino Sanfilippo <LinoSanfilippo@....de>
Subject: Re: [PATCH 3/3] serial: Add kserial_rs485 to avoid wasted space due
 to .padding

On Fri, 26 Aug 2022, Andy Shevchenko wrote:

> On Fri, Aug 26, 2022 at 5:51 PM Ilpo Järvinen
> <ilpo.jarvinen@...ux.intel.com> wrote:
> 
> > -static int user_rs485_to_kernel_serial_rs485(struct serial_rs485 *rs485,
> > +static int user_rs485_to_kernel_serial_rs485(struct kserial_rs485 *rs485,
> >                                              const struct serial_rs485 __user *rs485_user)
> >  {
> > -       if (copy_from_user(rs485, rs485_user, sizeof(*rs485)))
> > +       struct serial_rs485 rs485_uapi;
> > +
> > +       if (copy_from_user(&rs485_uapi, rs485_user, sizeof(*rs485)))
> >                 return -EFAULT;
> 
> > +       *rs485 = *((struct kserial_rs485 *)&rs485_uapi);
> 
> So with all assets we have we can be sure that on BE64 / BE32 machines
> this will be flawless. Is this assumption correct?

I think so. At worst it could trigger a build fail assuming the kernel 
would do some really odd struct layout reordering (which, according to 
the build bot, doesn't occur for any currently tested arch).

Now that you highlighted this line though, I started to wonder if it would 
be just better to use memcpy() instead as it would avoid those casts.

> > + * padding.
> > + */
> > +struct kserial_rs485 {
> > +       __u32   flags;                  /* RS485 feature flags */
> > +       __u32   delay_rts_before_send;  /* Delay before send (milliseconds) */
> > +       __u32   delay_rts_after_send;   /* Delay after send (milliseconds) */
> > +       struct {
> > +               __u8    addr_recv;
> > +               __u8    addr_dest;
> > +       };
> 
> Btw, can't we convert them to kernel doc?

Yes, why not.

-- 
 i.