On Sat, 2008-07-26 at 01:39 -0700, Andrew Morton wrote:
>
> Begin forwarded message:
>
> Date: Mon, 21 Jul 2008 15:18:46 +0200
> From: Olaf Hering <[email protected]>
> To: [email protected]
> Subject: asm-x86/byteorder.h, CONFIG_X86_BSWAP leaks to userland
> What is the purpose of CONFIG_X86_BSWAP in asm-x86/byteorder.h?
>
> An undefined CONFIG_foo defaults to 0 (I think), so bswap is never used.
> Is this done on purpose, or can the CONFIG_ foo be moved inside
> __KERNEL__ somehow?
I believe it's there to prevent the bswap instruction from being used on
early x86_32 models (i386/i486). As this will be 0 in userspace it is
effectively never using the bswap instruction for these routines.
I'm not sure if it's time yet to make the bswap ones be exported, as they
would no longer be usable for those early machines. X86 guys CC:d.
Harvey
Harvey Harrison wrote:
>>
>> An undefined CONFIG_foo defaults to 0 (I think), so bswap is never used.
>> Is this done on purpose, or can the CONFIG_ foo be moved inside
>> __KERNEL__ somehow?
>
> I believe it's there to prevent the bswap instruction from being used on
> early x86_32 models (i386/i486). As this will be 0 in userspace it is
> effectively never using the bswap instruction for these routines.
>
i386, specifically.
However, you shouldn't leak these symbols to userspace; there is a
warning option in gcc for undefined macros, and it's a *good thing* to
use it. Causing warnings in user space is not nice.
> I'm not sure if it's time yet to make the bswap ones be exported, as they
> would no longer be usable for those early machines. X86 guys CC:d.
On i386 we still default to i386-compatible binaries; I *think* gcc has
macros telling you if the user has used -march=i486 etc.
-hpa
On Sat, 26 Jul 2008 12:48:31 -0400
"H. Peter Anvin" <[email protected]> w
> > I'm not sure if it's time yet to make the bswap ones be exported,
> > as they would no longer be usable for those early machines. X86
> > guys CC:d.
>
> On i386 we still default to i386-compatible binaries; I *think* gcc
> has macros telling you if the user has used -march=i486 etc.
It is also not the kernels job to provide this sort of functionality to
userspace programs. At all. This is gcc/glibc/etc's job.
Rule of thumb: the kernel does not provide code for compiling inside
userspace programs.
(As opposed to providing datastructures that userspace programs can use
to talk to the kernel).
--
If you want to reach me at my work email, use [email protected]
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
On Sat, 2008-07-26 at 12:48 -0400, H. Peter Anvin wrote:
> Harvey Harrison wrote:
> >>
> >> An undefined CONFIG_foo defaults to 0 (I think), so bswap is never used.
> >> Is this done on purpose, or can the CONFIG_ foo be moved inside
> >> __KERNEL__ somehow?
> >
> > I believe it's there to prevent the bswap instruction from being used on
> > early x86_32 models (i386/i486). As this will be 0 in userspace it is
> > effectively never using the bswap instruction for these routines.
> >
>
> i386, specifically.
>
> However, you shouldn't leak these symbols to userspace; there is a
> warning option in gcc for undefined macros, and it's a *good thing* to
> use it. Causing warnings in user space is not nice.
True, but the existing header in Linus' tree does exactly this, so unless
you beat me to it, I'll have a look to see what can be done here.
>
> > I'm not sure if it's time yet to make the bswap ones be exported, as they
> > would no longer be usable for those early machines. X86 guys CC:d.
>
> On i386 we still default to i386-compatible binaries; I *think* gcc has
> macros telling you if the user has used -march=i486 etc.
>
Hmm, I wasn't aware of that, hopefully google will oblige.
Cheers,
Harvey
Arjan van de Ven wrote:
\>
> It is also not the kernels job to provide this sort of functionality to
> userspace programs. At all. This is gcc/glibc/etc's job.
>
> Rule of thumb: the kernel does not provide code for compiling inside
> userspace programs.
>
> (As opposed to providing datastructures that userspace programs can use
> to talk to the kernel).
>
That's a fine rule of thumb, but we have 17 years of legacy to deal with
here, too.
-hpa