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: <alpine.LFD.0.999.0708151809420.16414@enigma.security.iitk.ac.in>
Date:	Wed, 15 Aug 2007 18:32:10 +0530 (IST)
From:	Satyam Sharma <satyam@...radead.org>
To:	Herbert Xu <herbert@...dor.apana.org.au>
cc:	Andi Kleen <ak@...e.de>, sebastian@...akpoint.cc,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [patch 1/2] i386: use asm() like the other atomic operations
 already do.



On Wed, 15 Aug 2007, Herbert Xu wrote:

> Andi Kleen <ak@...e.de> wrote:
> >> My config with march=pentium-m and gcc (GCC) 4.1.2 (Gentoo 4.1.2):
> >>   text    data     bss     dec     hex filename
> >> 3434150  249176  176128 3859454  3ae3fe atomic_normal/vmlinux
> >> 3435308  249176  176128 3860612  3ae884 atomic_inlineasm/vmlinux
> > 
> > What is the difference between atomic_normal and atomic_inlineasm? 
> 
> The inline asm stops certain optimisations from occuring.

Yup, the "__volatile__" after "__asm__" shouldn't be required. The
previous definitions allowed the compiler to optimize certain atomic
ops away, and considering we haven't seen any bugs due to the past
behaviour anyway, changing it like this sounds unnecessary.

The second behavioral change that comes about here is the force-
constraining of v->counter to memory in the extended asm's constraint
sets. But that's required to give "volatility"-like behaviour, which
I suspect is the goal of this patch.

Sebastian, could you look at the kernel images in detail and see why,
how and what in the text expanded by 1158 bytes with these changes?


> I'm still unconvinced why we need this because nobody has
> brought up any examples of kernel code that legitimately
> need this.

Me too, but I do find these more palatable than the variants using
"volatile", I admit.


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