linux-kernel - Re: [PATCH] x86: include ENTRY/END in entry handlers in entry

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] [day] [month] [year] [list]

Date:	Mon, 24 Nov 2008 10:07:07 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Alexander van Heukelum <heukelum@...lshack.com>
CC:	Cyrill Gorcunov <gorcunov@...il.com>, Ingo Molnar <mingo@...e.hu>,
	LKML <linux-kernel@...r.kernel.org>,
	Andi Kleen <andi@...stfloor.org>,
	Jan Beulich <jbeulich@...ell.com>,
	Glauber Costa <gcosta@...hat.com>,
	Matt Mackall <mpm@...enic.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Nick Piggin <nickpiggin@...oo.com.au>
Subject: Re: [PATCH] x86: include ENTRY/END in entry handlers in entry_64.S

Alexander van Heukelum wrote:
> 
> Hello hpa,
> 
> KPROBE_ENTRY_P5ALIGNED It isn't better, that's the point.
> It's needed, because we have this problem:
> 
> 	.p2align 5
> 	KPROBE_ENTRY(something)
> 		somecode	
> 	KPROBE_END(something)
> 
> This does not align "something", because something is not in the
> same section as the ".p2align 5".
> 

I think that is braindamaged.  If KPROBE_ENTRY() changes the section
behind the programmers back, that's completely and totally stupid in an
utterly reckless sort of way.  The author of a macro like that should be
taken out and shot, because it makes the programmer think the code does
something completely different than what the code actually does.

This isn't merely ugly, it is downright dangerous.

>> For the record, I think we already have way to much macro crappage.  It
>> makes the code painful to read and hard to figure out what the real
>> constraints on it is.
> 
> I agree with that to some point. But even without the macro's, the
> code is hard to read. As an alternative to more macro's, what do you
> think of Cyrills suggestion of putting CFI-annotations next to the
> instuctions, like:
> 
> 	pushq %rax			; CFI_ADJUST_CFA_OFFSET 8
> 	movq %rax, RAX+8(%rsp)		; CFI_REL_OFFSET rax, RAX+8
> 
> instead? That still leaves the problem that the instruction and the
> annotation might not match, but it leaves the code more readable for
> someone who is used to reading x86 assembly.

I think using the macros for opcodes make sense, as the CFI operation is
tied to the operation.  That is a good way to use macros.

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