On 06/08/2015 03:24 PM, tip-bot for Ingo Molnar wrote:
> Commit-ID: bace7117d3fb59a6ed7ea1aa6c8994df6a28a72a
> Gitweb: http://git.kernel.org/tip/bace7117d3fb59a6ed7ea1aa6c8994df6a28a72a
> Author: Ingo Molnar <[email protected]>
> AuthorDate: Mon, 8 Jun 2015 21:20:26 +0200
> Committer: Ingo Molnar <[email protected]>
> CommitDate: Mon, 8 Jun 2015 23:43:38 +0200
>
> x86/asm/entry: (Re-)rename __NR_entry_INT80_compat_max to __NR_syscall_compat_max
>
> Brian Gerst noticed that I did a weird rename in the following commit:
>
> b2502b418e63 ("x86/asm/entry: Untangle 'system_call' into two entry points: entry_SYSCALL_64 and entry_INT80_32")
>
> which renamed __NR_ia32_syscall_max to __NR_entry_INT80_compat_max.
>
> Now the original name was a misnomer, but the new one is a misnomer as well,
> as all the 32-bit compat syscall entry points (sysenter, syscall) share the
> system call table, not just the INT80 based one.
>
> Rename it to __NR_syscall_compat_max.
>
The original one wasn't really a misnomer, as it referred to the ia32
system calls specifically, but this works too.
-hpa
* H. Peter Anvin <[email protected]> wrote:
> On 06/08/2015 03:24 PM, tip-bot for Ingo Molnar wrote:
> > Commit-ID: bace7117d3fb59a6ed7ea1aa6c8994df6a28a72a
> > Gitweb: http://git.kernel.org/tip/bace7117d3fb59a6ed7ea1aa6c8994df6a28a72a
> > Author: Ingo Molnar <[email protected]>
> > AuthorDate: Mon, 8 Jun 2015 21:20:26 +0200
> > Committer: Ingo Molnar <[email protected]>
> > CommitDate: Mon, 8 Jun 2015 23:43:38 +0200
> >
> > x86/asm/entry: (Re-)rename __NR_entry_INT80_compat_max to __NR_syscall_compat_max
> >
> > Brian Gerst noticed that I did a weird rename in the following commit:
> >
> > b2502b418e63 ("x86/asm/entry: Untangle 'system_call' into two entry points: entry_SYSCALL_64 and entry_INT80_32")
> >
> > which renamed __NR_ia32_syscall_max to __NR_entry_INT80_compat_max.
> >
> > Now the original name was a misnomer, but the new one is a misnomer as well,
> > as all the 32-bit compat syscall entry points (sysenter, syscall) share the
> > system call table, not just the INT80 based one.
> >
> > Rename it to __NR_syscall_compat_max.
> >
>
> The original one wasn't really a misnomer, as it referred to the ia32
> system calls specifically, but this works too.
It was a misnomer, because what are the 'ia32 system calls'? We have no Intel
specific system calls!
The term 'IA32' (Intel Architecture 32-bit) is a misnomer in many existing
arch/x86/ symbol, function and file names, and most of them should be renamed.
Some common examples, with a suggested rename target:
stack_frame_ia32 -> stack_frame_compat
IA32_RT_SIGFRAME_sigcontext -> COMPAT_RT_SIGFRAME_sigcontext
sigcontext_ia32 -> sigcontext_compat
user_i387_ia32_struct -> user_i387_compat_struct
TIF_IA32 -> TIF_COMPAT
and here a few 'ia32' misnomers that should be addressed not via simple renames,
but via transformations to existing compat facilities:
CONFIG_IA32_EMULATION -> partly eliminate, partly covert to CONFIG_COMPAT use
is_ia32_task() -> convert to is_compat_task() use
This holds for file names as well, for example:
arch/x86/ia32/ -> arch/x86/compat/
arch/x86/ia32/ia32_aout.c -> arch/x86/compat/aout.c
arch/x86/ia32/ia32_signal.c -> arch/x86/compat/signal.c
arch/x86/ia32/sys_ia32.c -> arch/x86/compat/sys.c
There are a number of symbols where the 'IA32' name is probably fine: for example
the various Intel-specific MSR names - or even cross-CPU MSR names that AMD uses
but which got first introduced on Intel CPUs.
For generic names that deal with 32-bit compat, 'ia32' is a misnomer.
If there's consensus for the above (re-)naming schemes I can start doing them.
Thanks,
Ingo
On Thu, Jun 18, 2015 at 12:49 PM, Ingo Molnar <[email protected]> wrote:
>
> * H. Peter Anvin <[email protected]> wrote:
>
>> On 06/08/2015 03:24 PM, tip-bot for Ingo Molnar wrote:
>> > Commit-ID: bace7117d3fb59a6ed7ea1aa6c8994df6a28a72a
>> > Gitweb: http://git.kernel.org/tip/bace7117d3fb59a6ed7ea1aa6c8994df6a28a72a
>> > Author: Ingo Molnar <[email protected]>
>> > AuthorDate: Mon, 8 Jun 2015 21:20:26 +0200
>> > Committer: Ingo Molnar <[email protected]>
>> > CommitDate: Mon, 8 Jun 2015 23:43:38 +0200
>> >
>> > x86/asm/entry: (Re-)rename __NR_entry_INT80_compat_max to __NR_syscall_compat_max
>> >
>> > Brian Gerst noticed that I did a weird rename in the following commit:
>> >
>> > b2502b418e63 ("x86/asm/entry: Untangle 'system_call' into two entry points: entry_SYSCALL_64 and entry_INT80_32")
>> >
>> > which renamed __NR_ia32_syscall_max to __NR_entry_INT80_compat_max.
>> >
>> > Now the original name was a misnomer, but the new one is a misnomer as well,
>> > as all the 32-bit compat syscall entry points (sysenter, syscall) share the
>> > system call table, not just the INT80 based one.
>> >
>> > Rename it to __NR_syscall_compat_max.
>> >
>>
>> The original one wasn't really a misnomer, as it referred to the ia32
>> system calls specifically, but this works too.
>
> It was a misnomer, because what are the 'ia32 system calls'? We have no Intel
> specific system calls!
>
> The term 'IA32' (Intel Architecture 32-bit) is a misnomer in many existing
> arch/x86/ symbol, function and file names, and most of them should be renamed.
>
> Some common examples, with a suggested rename target:
>
> stack_frame_ia32 -> stack_frame_compat
> IA32_RT_SIGFRAME_sigcontext -> COMPAT_RT_SIGFRAME_sigcontext
> sigcontext_ia32 -> sigcontext_compat
> user_i387_ia32_struct -> user_i387_compat_struct
> TIF_IA32 -> TIF_COMPAT
>
> and here a few 'ia32' misnomers that should be addressed not via simple renames,
> but via transformations to existing compat facilities:
>
> CONFIG_IA32_EMULATION -> partly eliminate, partly covert to CONFIG_COMPAT use
I think we still want a symbol for code that is exclusive to 32-bit
compatibility (like entry and signal code) to keep it separate from
X32 which also wants CONFIG_COMPAT. If I get time this weekend I'll
get the patchset to do the separation updated to the tip branch.
> is_ia32_task() -> convert to is_compat_task() use
>
> This holds for file names as well, for example:
>
> arch/x86/ia32/ -> arch/x86/compat/
> arch/x86/ia32/ia32_aout.c -> arch/x86/compat/aout.c
> arch/x86/ia32/ia32_signal.c -> arch/x86/compat/signal.c
> arch/x86/ia32/sys_ia32.c -> arch/x86/compat/sys.c
>
> There are a number of symbols where the 'IA32' name is probably fine: for example
> the various Intel-specific MSR names - or even cross-CPU MSR names that AMD uses
> but which got first introduced on Intel CPUs.
>
> For generic names that deal with 32-bit compat, 'ia32' is a misnomer.
>
> If there's consensus for the above (re-)naming schemes I can start doing them.
As long as there is no confusion between this and X32, I am fine with it.
--
Brian Gerst
We have generally used i386 as opposed to x86 for that purpose. IA32 in MSR names is part of the MSR name and should not be taken out.
On June 18, 2015 10:49:33 AM PDT, Brian Gerst <[email protected]> wrote:
>On Thu, Jun 18, 2015 at 12:49 PM, Ingo Molnar <[email protected]> wrote:
>>
>> * H. Peter Anvin <[email protected]> wrote:
>>
>>> On 06/08/2015 03:24 PM, tip-bot for Ingo Molnar wrote:
>>> > Commit-ID: bace7117d3fb59a6ed7ea1aa6c8994df6a28a72a
>>> > Gitweb:
>http://git.kernel.org/tip/bace7117d3fb59a6ed7ea1aa6c8994df6a28a72a
>>> > Author: Ingo Molnar <[email protected]>
>>> > AuthorDate: Mon, 8 Jun 2015 21:20:26 +0200
>>> > Committer: Ingo Molnar <[email protected]>
>>> > CommitDate: Mon, 8 Jun 2015 23:43:38 +0200
>>> >
>>> > x86/asm/entry: (Re-)rename __NR_entry_INT80_compat_max to
>__NR_syscall_compat_max
>>> >
>>> > Brian Gerst noticed that I did a weird rename in the following
>commit:
>>> >
>>> > b2502b418e63 ("x86/asm/entry: Untangle 'system_call' into two
>entry points: entry_SYSCALL_64 and entry_INT80_32")
>>> >
>>> > which renamed __NR_ia32_syscall_max to
>__NR_entry_INT80_compat_max.
>>> >
>>> > Now the original name was a misnomer, but the new one is a
>misnomer as well,
>>> > as all the 32-bit compat syscall entry points (sysenter, syscall)
>share the
>>> > system call table, not just the INT80 based one.
>>> >
>>> > Rename it to __NR_syscall_compat_max.
>>> >
>>>
>>> The original one wasn't really a misnomer, as it referred to the
>ia32
>>> system calls specifically, but this works too.
>>
>> It was a misnomer, because what are the 'ia32 system calls'? We have
>no Intel
>> specific system calls!
>>
>> The term 'IA32' (Intel Architecture 32-bit) is a misnomer in many
>existing
>> arch/x86/ symbol, function and file names, and most of them should be
>renamed.
>>
>> Some common examples, with a suggested rename target:
>>
>> stack_frame_ia32 -> stack_frame_compat
>> IA32_RT_SIGFRAME_sigcontext -> COMPAT_RT_SIGFRAME_sigcontext
>> sigcontext_ia32 -> sigcontext_compat
>> user_i387_ia32_struct -> user_i387_compat_struct
>> TIF_IA32 -> TIF_COMPAT
>>
>> and here a few 'ia32' misnomers that should be addressed not via
>simple renames,
>> but via transformations to existing compat facilities:
>>
>> CONFIG_IA32_EMULATION -> partly eliminate, partly covert to
>CONFIG_COMPAT use
>
>I think we still want a symbol for code that is exclusive to 32-bit
>compatibility (like entry and signal code) to keep it separate from
>X32 which also wants CONFIG_COMPAT. If I get time this weekend I'll
>get the patchset to do the separation updated to the tip branch.
>
>> is_ia32_task() -> convert to is_compat_task() use
>>
>> This holds for file names as well, for example:
>>
>> arch/x86/ia32/ -> arch/x86/compat/
>> arch/x86/ia32/ia32_aout.c -> arch/x86/compat/aout.c
>> arch/x86/ia32/ia32_signal.c -> arch/x86/compat/signal.c
>> arch/x86/ia32/sys_ia32.c -> arch/x86/compat/sys.c
>>
>> There are a number of symbols where the 'IA32' name is probably fine:
>for example
>> the various Intel-specific MSR names - or even cross-CPU MSR names
>that AMD uses
>> but which got first introduced on Intel CPUs.
>>
>> For generic names that deal with 32-bit compat, 'ia32' is a misnomer.
>>
>> If there's consensus for the above (re-)naming schemes I can start
>doing them.
>
>As long as there is no confusion between this and X32, I am fine with
>it.
>
>--
>Brian Gerst
--
Sent from my mobile phone. Please pardon brevity and lack of formatting.
The issue with that is that "compat" is a cross-architecture feature of the kernel to handle *some* 32-on-64 bit ABI translations. x32 uses *some* but not all of the compat machinery.
It is already confusing when you introduce more than two ABIs (e.g. x32 or MIPS n32) and we need a way to be able to be specific. I suggest using i386 or just use ia32 as a legacy symbol name.
On June 18, 2015 11:14:45 AM PDT, Linus Torvalds <[email protected]> wrote:
>On Jun 18, 2015 7:49 AM, "Brian Gerst" <[email protected]> wrote:
>>
>> As long as there is no confusion between this and X32, I am fine with
>it.
>
>I would suggest that we use "compat" for the traditional 32-bit x86
>code,
>and x32 for the x32/ones. That sounds very natural and unambiguous to
>me..
>
> Linus
--
Sent from my mobile phone. Please pardon brevity and lack of formatting.
* Brian Gerst <[email protected]> wrote:
> >> The original one wasn't really a misnomer, as it referred to the ia32 system
> >> calls specifically, but this works too.
> >
> > It was a misnomer, because what are the 'ia32 system calls'? We have no Intel
> > specific system calls!
> >
> > The term 'IA32' (Intel Architecture 32-bit) is a misnomer in many existing
> > arch/x86/ symbol, function and file names, and most of them should be renamed.
> >
> > Some common examples, with a suggested rename target:
> >
> > stack_frame_ia32 -> stack_frame_compat
> > IA32_RT_SIGFRAME_sigcontext -> COMPAT_RT_SIGFRAME_sigcontext
> > sigcontext_ia32 -> sigcontext_compat
> > user_i387_ia32_struct -> user_i387_compat_struct
> > TIF_IA32 -> TIF_COMPAT
> >
> > and here a few 'ia32' misnomers that should be addressed not via simple renames,
> > but via transformations to existing compat facilities:
> >
> > CONFIG_IA32_EMULATION -> partly eliminate, partly covert to CONFIG_COMPAT use
>
> I think we still want a symbol for code that is exclusive to 32-bit
> compatibility (like entry and signal code) to keep it separate from X32 which
> also wants CONFIG_COMPAT. If I get time this weekend I'll get the patchset to
> do the separation updated to the tip branch.
Ok, so your goal is to allow the x32 ABI, but not 32-bit user-space?
I suppose that makes some sense, it might be a valid 'attack surface reduction'
technique, while still allowing the x32 ABI.
But I'm not sure we should bother and complicate things: 32-bit compat isn't going
away anytime soon, and most of CONFIG_COMPAT is needed for x32.
So maybe we could introduce CONFIG_X86_32_ABI=y or so, which would cover just the
32-bit entry code and the signal frame compatibility layer?
Thanks,
Ingo
On Thu, Jun 18, 2015 at 5:13 PM, Ingo Molnar <[email protected]> wrote:
>
> * Brian Gerst <[email protected]> wrote:
>
>> >> The original one wasn't really a misnomer, as it referred to the ia32 system
>> >> calls specifically, but this works too.
>> >
>> > It was a misnomer, because what are the 'ia32 system calls'? We have no Intel
>> > specific system calls!
>> >
>> > The term 'IA32' (Intel Architecture 32-bit) is a misnomer in many existing
>> > arch/x86/ symbol, function and file names, and most of them should be renamed.
>> >
>> > Some common examples, with a suggested rename target:
>> >
>> > stack_frame_ia32 -> stack_frame_compat
>> > IA32_RT_SIGFRAME_sigcontext -> COMPAT_RT_SIGFRAME_sigcontext
>> > sigcontext_ia32 -> sigcontext_compat
>> > user_i387_ia32_struct -> user_i387_compat_struct
>> > TIF_IA32 -> TIF_COMPAT
>> >
>> > and here a few 'ia32' misnomers that should be addressed not via simple renames,
>> > but via transformations to existing compat facilities:
>> >
>> > CONFIG_IA32_EMULATION -> partly eliminate, partly covert to CONFIG_COMPAT use
>>
>> I think we still want a symbol for code that is exclusive to 32-bit
>> compatibility (like entry and signal code) to keep it separate from X32 which
>> also wants CONFIG_COMPAT. If I get time this weekend I'll get the patchset to
>> do the separation updated to the tip branch.
>
> Ok, so your goal is to allow the x32 ABI, but not 32-bit user-space?
It just seems odd that x32 (which is really a 64-bit ABI with 32-bit
pointers) depended on enabling 32-bit support. Other than both using
the core compat code, they are not really related.
> I suppose that makes some sense, it might be a valid 'attack surface reduction'
> technique, while still allowing the x32 ABI.
>
> But I'm not sure we should bother and complicate things: 32-bit compat isn't going
> away anytime soon, and most of CONFIG_COMPAT is needed for x32.
Many of the compat syscalls are unused by x32. It only needs to
handle syscalls with pointers embedded in data structures differently
than native 64-bit. 64-bit integer arguments (ie., loff_t) do not
need special handling, since they can be passed in a single register
instead of a pair of 32-bit registers. This won't solve that
particular issue yet, but it's something to be aware of for future
cleanups.
> So maybe we could introduce CONFIG_X86_32_ABI=y or so, which would cover just the
> 32-bit entry code and the signal frame compatibility layer?
Yes.
--
Brian Gerst
* Brian Gerst <[email protected]> wrote:
> > Ok, so your goal is to allow the x32 ABI, but not 32-bit user-space?
>
> It just seems odd that x32 (which is really a 64-bit ABI with 32-bit pointers)
> depended on enabling 32-bit support. Other than both using the core compat
> code, they are not really related.
Yeah.
> > I suppose that makes some sense, it might be a valid 'attack surface
> > reduction' technique, while still allowing the x32 ABI.
> >
> > But I'm not sure we should bother and complicate things: 32-bit compat isn't
> > going away anytime soon, and most of CONFIG_COMPAT is needed for x32.
>
> Many of the compat syscalls are unused by x32. It only needs to handle syscalls
> with pointers embedded in data structures differently than native 64-bit.
Yeah, but in fact those are the 'most interesting' (read: most complex) aspects of
the generic compat machinery. So most of the 'core compat' functionality is used -
even though we don't use many of the (trivial) argument-converted syscall
variants.
> 64-bit integer arguments (ie., loff_t) do not need special handling, since they
> can be passed in a single register instead of a pair of 32-bit registers. This
> won't solve that particular issue yet, but it's something to be aware of for
> future cleanups.
Yes, and I think 'X32' is a misnomer in that sense: in reality it's a 90% 64-bit
ABI that just happens to have a handful of additional system calls that can deal
with data pointers truncated to 32 bits.
So 'C64' would have been a better name: a compacted 64-bit ABI - but that
particular name has its own problems ;-) Maybe S64 (small 64-bit memory model)?
'S64' would also have been an easier sell to distros: they generally resist adding
anything that smells old, 32-bit ... but kernel hackers and marketing were always
somewhat disjunct sets ;-)
I'm wondering whether we'll ever see a 48-bit user-space pointer model ;-) They
are misaligned by 32 bits, but x86 CPUs generally handle 32-bit misalignment just
fine. The killer would be to zero-extend from 48 bits to 64 bits I suspect -
there's no natural instruction for that.
> > So maybe we could introduce CONFIG_X86_32_ABI=y or so, which would cover just
> > the 32-bit entry code and the signal frame compatibility layer?
>
> Yes.
Ok, then it sounds good to me!
Thanks,
Ingo
* H. Peter Anvin <[email protected]> wrote:
> We have generally used i386 as opposed to x86 for that purpose. [...]
So 'i386' is really the original name that stuck.
'x86-32' sounds more appropriate to me - we should not perpetuate the i386 name,
as we don't run on an original i386 anymore ;-)
Here's what I think sounds pretty natural:
CONFIG_X86_32_ABI
CONFIG_X86_64_ABI
CONFIG_X86_X32_ABI
- CONFIG_X86_X32_ABI and CONFIG_X86_32_ABI selects CONFIG_COMPAT.
- CONFIG_X86_32_ABI enables the 32-bit/32-bit system call ABI.
- CONFIG_X86_X32_ABI enables the extra 64-bit/32-bit system call entries.
- CONFIG_IA32_EMULATION goes away.
> [...] IA32 in MSR names is part of the MSR name and should not be taken out.
Yes, of course.
Thanks,
Ingo
x86-32 is clumsy though. "Original name that stuck" is perfectly legitimate, and having multiple names for the same thing is always worse then having slightly imperfect names.
On June 19, 2015 12:13:05 AM PDT, Ingo Molnar <[email protected]> wrote:
>
>* H. Peter Anvin <[email protected]> wrote:
>
>> We have generally used i386 as opposed to x86 for that purpose. [...]
>
>So 'i386' is really the original name that stuck.
>
>'x86-32' sounds more appropriate to me - we should not perpetuate the
>i386 name,
>as we don't run on an original i386 anymore ;-)
>
>Here's what I think sounds pretty natural:
>
> CONFIG_X86_32_ABI
> CONFIG_X86_64_ABI
> CONFIG_X86_X32_ABI
>
>- CONFIG_X86_X32_ABI and CONFIG_X86_32_ABI selects CONFIG_COMPAT.
>- CONFIG_X86_32_ABI enables the 32-bit/32-bit system call ABI.
>- CONFIG_X86_X32_ABI enables the extra 64-bit/32-bit system call
>entries.
>- CONFIG_IA32_EMULATION goes away.
>
>> [...] IA32 in MSR names is part of the MSR name and should not be
>taken out.
>
>Yes, of course.
>
>Thanks,
>
> Ingo
--
Sent from my mobile phone. Please pardon brevity and lack of formatting.
* H. Peter Anvin <[email protected]> wrote:
> x86-32 is clumsy though. "Original name that stuck" is perfectly legitimate,
> and having multiple names for the same thing is always worse then having
> slightly imperfect names.
But at least for Kconfigs X86-32 is the name that is much more common:
triton:~/tip> make ARCH=i386 allmodconfig
triton:~/tip> grep _386 .config
triton:~/tip> grep _X86_32 .config
CONFIG_X86_32=y
CONFIG_X86_32_SMP=y
CONFIG_X86_32_LAZY_GS=y
CONFIG_X86_32_NON_STANDARD=y
CONFIG_X86_32_IRIS=m
So I'd go with that.
Also, since we have 'x86-64', not Not sure I'd consider 'x86-32' clumsy.
Thanks,
Ingo