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: <20080424.182834.104940176.yoshfuji@linux-ipv6.org>
Date:	Thu, 24 Apr 2008 18:28:34 +0900 (JST)
From:	YOSHIFUJI Hideaki / 吉藤英明 
	<yoshfuji@...ux-ipv6.org>
To:	davem@...emloft.net
Cc:	dlstevens@...ibm.com, netdev@...r.kernel.org,
	yoshfuji@...ux-ipv6.org
Subject: Re: [GIT PULL] [IPV6] COMPAT: Fix SSM applications on 64bit
 kernels.

In article <20080424.014956.94335109.davem@...emloft.net> (at Thu, 24 Apr 2008 01:49:56 -0700 (PDT)), David Miller <davem@...emloft.net> says:

> From: YOSHIFUJI Hideaki / 吉藤英明 <yoshfuji@...ux-ipv6.org>
> Date: Thu, 24 Apr 2008 17:16:44 +0900 (JST)
> 
> > In article <20080424.010845.257071066.davem@...emloft.net> (at Thu, 24 Apr 2008 01:08:45 -0700 (PDT)), David Miller <davem@...emloft.net> says:
> > 
> > > From: YOSHIFUJI Hideaki / 吉藤英明 <yoshfuji@...ux-ipv6.org>
> > > Date: Thu, 24 Apr 2008 17:02:57 +0900 (JST)
> > > 
> > > > +#ifdef __KERNEL__
> > > > +struct __compat_sockaddr_storage {
> > > > +	unsigned short  ss_family;
> > > > +	char		__data[_K_SS_MAXSIZE - sizeof(unsigned short)];
> > > > +} __attribute__ ((aligned(4)));
> > > > +#endif
> > > 
> > > Should include <linux/compat.h>, use compat types, and be guarded
> > > by CONFIG_COMPAT.  This goes for all such structures.
> > 
> > Do you mean, something like this?
> > 
> > #ifdef __KERNEL__
> > #include <linux/compat.h>
> > 
> > #ifdef CONFIG_COMPAT
> > struct __compat_sockaddr_storage {
> >    unsigned short  ss_family;
> >   char            __data[_K_SS_MAXSIZE - sizeof(unsigned short)];
> >  __attribute__ ((aligned(alignof(compat_uptr_t))));
> > #endif
> > #endif
> 
> I think first of all that ((packed)) is a better attribute to use than
> the explicit alignment.

Well, I don't think so.

Most (if not all) compat_XXX{} do not have such attribute,
and sockaddr_storage{} shuould actually be aligned on 32bit on
32bit archs, so I think we should declare, no?

For example, if we have
    struct foobar {
        char a;
        struct sockaddr_storage b;
    };
Then, offsetof(struct foobar, b) should be 4, not 1 nor 2.
(Of course all other fields of group_xxx structures are of
u32 here, so it is safe so far...)

Or, are you worrying about alignment of short?

--yoshfuji
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ