linux-kernel - Re: [PATCH 5/13] score - New architecure port to SunplusCT S+CORE processor

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] [day] [month] [year] [list]

Date:	Mon, 30 Mar 2009 10:25:26 +0800
From:	liqin.chen@...plusct.com
To:	Arnd Bergmann <arnd@...db.de>, Sam Ravnborg <sam@...nborg.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Kyle McMartin <kyle@...artin.ca>
Cc:	linux-arch@...r.kernel.org, linux-kernel@...r.kernel.org,
	torvalds@...ux-foundation.org
Subject: Re: [PATCH 5/13] score - New architecure port to SunplusCT S+CORE processor

Hi tglx, Arnd, Kyle and Sam,

        Thank you for your kindly reply, I will update 
        the code according to your comments.
        The fixed patches will be sent out soon.

-- 
Best regards
Liqin
liqin.chen@...plusct.com

Arnd Bergmann <arnd@...db.de> 写于 2009-03-28 04:53:05:

> On Friday 27 March 2009, Sam Ravnborg wrote:
> 
> > Thats strange indeed.
> > This structure will then change layout depending on the target 
bit-size
> > of the compiler.
> > 
> > From x86:
> > #ifdef __i386__
> >         unsigned long           __unused1;
> > #endif
> >         __kernel_time_t         shm_dtime;      /* last detach time */
> > #ifdef __i386__
> >         unsigned long           __unused2;
> > #endif
> > 
> > long is 64 bit in one case and 32 bit in another case.
> > I'm confused..
> 
> The idea here is to have the same layout for both by adding
> long (32 bit) padding between 32 bit members on i386 and not
> having the padding along the __kernel_time_t (which is also
> long) members on x86_64. The problem is that some architectures
> copying this didn't understand the part about the padding,
> while others (big-endian ones) put the padding in the wrong
> place by copying from i386.
> 
> By now, most of the existing architectures copied the i386
> file, which is at least consistent and we've learned to
> deal with it. I recommend just using this one as the
> asm-generic version and letting all new archs fall back
> to that.
> 
> > I would expect it to be safer to be bit-size neutral in our
> > exported headers.
> > But the score people know there userlend best so let them decide.
> 
> > Still they should audit all their exported headers.
> > They cannot assume it was right because they copied them from
> > somewhere.
> 
> Yes, I agree. Hopefully I'll manage to get my patches into
> shape to post the generic versions in the next days so we can use
> them on microblaze and score as well as all future versions.
> 
>    Arnd <><