linux-kernel - Re: [RFC,v2] x86_64: save

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: <49235178.2050108@goop.org>
Date:	Tue, 18 Nov 2008 15:36:24 -0800
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Andi Kleen <andi@...stfloor.org>
CC:	Roland McGrath <roland@...hat.com>, Ingo Molnar <mingo@...e.hu>,
	Jan Beulich <jbeulich@...ell.com>, heukelum@...tmail.fm,
	Thomas Gleixner <tglx@...utronix.de>,
	Alexander van Heukelum <heukelum@...lshack.com>,
	Glauber Costa <gcosta@...hat.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Nick Piggin <nickpiggin@...oo.com.au>,
	"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [RFC,v2] x86_64: save_args out of line

Andi Kleen wrote:
>> I don't think auto-generation is very a useful angle to take for this any
>> time soon.  Explicit (but simple) macros in the assembly is what I favor.
>>     
>
> Do you mean macros that generate both the instruction and the CFI
> or separate? The major disadvantage of doing it together in a 
> single macro is that it is not really readable for any assembler 
> programmer anymore, but starts becoming a Linux specific assembler 
> language. Likely not a good thing for maintenance. anyone who
> wants to know the real assembler would need to read objdump -S
> output, which is not nice.
>
> Perhaps it would be a reasonable readability improvement to just use shorter 
> cfi macros which are not shouted?

Not really.  At the moment we have two parallel assembly languages which 
say different things about the same instructions.  In practice, almost 
nobody understands the cfi parts, so they just get ignored while the x86 
instructions change around them, leaving them either stale or missing.

If we had a sensible macro layer which emits both instructions and cfi 
annotations, it at least means that people who write plain x86 
instructions will simply get no annotations, and people who bother to 
learn the (clearly and fully documented) macros will get the best of both.

    J
--
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/