linux-kernel - Re: [PATCH] x86, syscalls: use SYSCALL_DEFINE() macros for sys_modify

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]

Date:   Wed, 18 Oct 2017 15:17:47 +0200
From:   Ingo Molnar <mingo@...nel.org>
To:     Dave Hansen <dave.hansen@...ux.intel.com>
Cc:     linux-kernel@...r.kernel.org, x86@...nel.org, luto@...nel.org,
        brgerst@...il.com
Subject: Re: [PATCH] x86, syscalls: use SYSCALL_DEFINE() macros for
 sys_modify_ldt()


* Dave Hansen <dave.hansen@...ux.intel.com> wrote:

> 
> We do not have tracepoints for sys_modify_ldt() because we define
> it directly instead of using the normal SYSCALL_DEFINEx() macros.
> 
> However, there is a reason sys_modify_ldt() does not use the macros:
> it has an 'int' return type instead of 'unsigned long'.  This is
> a bug, but it's a bug cemented in the ABI.
> 
> What does this mean?  If we return -EINVAL from a function that
> returns 'int', we have 0x00000000ffffffea in %rax.  But, if we
> return -EINVAL from a function returning 'unsigned long', we end
> up with 0xffffffffffffffea in %rax, which is wrong.
> 
> To work around this and maintain the 'int' behavior while using
> the SYSCALL_DEFINEx() macros, so we add a cast to 'unsigned int'
> in both implementations of sys_modify_ldt().
> 
> Cc: x86@...nel.org
> Cc: Andy Lutomirski <luto@...nel.org>
> Cc: Brian Gerst <brgerst@...il.com>

I have added your:

  Signed-off-by: Dave Hansen <dave.hansen@...ux.intel.com>

let me know if that's OK.

Thanks,

	Ingo