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:	Fri, 23 Jan 2009 19:17:21 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Török Edwin <edwintorok@...il.com>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: inline asm semantics: output constraint width smaller than
	input


* Török Edwin <edwintorok@...il.com> wrote:

> Hi,
> 
> I am trying to build the kernel with LLVM 2.5 prerelease (using 
> llvm-gcc-4.2 frontend), however I am running into some inline asm 
> semantics issues, and after some discussion on LLVM bugzilla I would 
> like to know if you would be accepting patches for this: 
> http://llvm.org/bugs/show_bug.cgi?id=3373
> 
> The problem is when "a" output constraint is used with a variable of 
> smaller width than the "0" input constraint.
> 
> Here are 2 examples:
> 
> int __ret_pu; unsigned long __pu_val;
> return   ({asm volatile("call __put_user_" "8" : "=a" (__ret_pu) :"0"
>                           (__pu_val), "c"(addr) : "ebx"); __ret_pu;});
> 
> 
> unsigned char return_code;      /* %al */         
> unsigned long address;          /* %ebx */ 
> unsigned long length;           /* %ecx */
> unsigned long entry;            /* %edx */
> unsigned long flags;
> __asm__("lcall *(%%edi); cld"
>                 : "=a" (return_code),
>                   "=b" (address),
>                   "=c" (length),
>                   "=d" (entry)
>                 : "0" (service),
>                   "1" (0),
>                   "D" (&bios32_indirect));
> 
> There are 2 cases:
> 1. output is wider than input
> 2. output is narrower than input
> 
> Case 2 seems to occur lots of times on 64-bit (due to sizeof(int) != 
> sizeof(unsigned long)), and a few times on 32-bit as well.
> 
> Would you accept patches that increase the portability of the inline asm 
> statements? (essentially by adding casts for case 1, and introducing a 
> temporary of correct width for case 2).

i'd not mind it at all if the kernel could be built with other open-source 
compilers too.

Now in this case the patch you suggest might end up hurting the end result 
so it's not an unconditional 'yes'. But ... how much it actually matters 
depends on the circumstances.

So could you please send a sample patch for some of most common inline 
assembly statements that are affected by this, so that we can see:

   1) how ugly the LLVM workarounds are
   2) how they affect the generated kernel image in practice

My gut feeling is that it's going to be acceptable with a bit of thinking 
(we might even do some wrappers to do this cleanly) - but i'd really like 
to see it before giving you that judgement.

Another question: does LLVM always warn about such input/output aliased 
constraint width mismatch problems if they occur, or does it silently 
corrupt the resulting instruction sequence?

	Ingo
--
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