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: <9E143C8F-1F0D-4528-B354-30BB68CCBC0E@zytor.com>
Date:	Thu, 18 Jun 2015 12:37:01 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Brian Gerst <brgerst@...il.com>, Ingo Molnar <mingo@...nel.org>
CC:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Borislav Petkov <bp@...en8.de>,
	Thomas Gleixner <tglx@...utronix.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Denys Vlasenko <dvlasenk@...hat.com>,
	Andy Lutomirski <luto@...capital.net>,
	linux-tip-commits@...r.kernel.org
Subject: Re: [RFC] Rename various 'IA32' uses in arch/x86/ code

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 <brgerst@...il.com> wrote:
>On Thu, Jun 18, 2015 at 12:49 PM, Ingo Molnar <mingo@...nel.org> wrote:
>>
>> * H. Peter Anvin <hpa@...or.com> 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 <mingo@...nel.org>
>>> > AuthorDate: Mon, 8 Jun 2015 21:20:26 +0200
>>> > Committer:  Ingo Molnar <mingo@...nel.org>
>>> > 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ