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

Message-ID: <20081124100604.GB8187@mailshack.com>
Date:	Mon, 24 Nov 2008 11:06:05 +0100
From:	Alexander van Heukelum <heukelum@...lshack.com>
To:	"H. Peter Anvin" <hpa@...or.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

On Sun, Nov 23, 2008 at 12:13:18PM -0800, H. Peter Anvin wrote:
> Alexander van Heukelum wrote:
> > 
> > I put a ".p2align 5" in earlier in the series which caused the
> > apicinterrupts to be 32-byte aligned. But it is a hack, really,
> > relying on the generated code per stub to be between 17 and 32
> > bytes, on the default alignment to be 16 bytes and all stubs
> > to be in the .text section.
> > 
> > I'm in favour of aligning all of the interrupt/exception stubs
> > to 32 bytes, but it should be implemented the right way ;),
> > which means that we need KPROBE_ENTRY_P5ALIGNED and so on :-/.
> > 
> 
> I'm sorry, I really don't follow that logic at all.  Why the heck would
> KPROBE_ENTRY_P5ALIGNED be better than .p5align?

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".

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

Greetings,
	Alexander

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