linux-kernel - Re: [RFC] x86: 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]

Date:	Mon, 17 Nov 2008 16:13:17 +0100
From:	"Alexander van Heukelum" <heukelum@...tmail.fm>
To:	"Glauber Costa" <glommer@...hat.com>
Cc:	"Ingo Molnar" <mingo@...e.hu>,
	"LKML" <linux-kernel@...r.kernel.org>,
	"Andi Kleen" <andi@...stfloor.org>,
	"Alexander van Heukelum" <heukelum@...i.uni-sb.de>,
	"Glauber Costa" <gcosta@...hat.com>
Subject: Re: [RFC] x86: save_args out of line

On Mon, 17 Nov 2008 10:14:44 -0200, "Glauber Costa" <glommer@...hat.com>
said:
> On Sun, Nov 16, 2008 at 03:29:01PM +0100, Alexander van Heukelum wrote:
> > From: Alexander van Heukelum <heukelum@...ipnir.lusi.uni-sb.de>
> > 
> > The macro "interrupt" in entry_64.S generates a lot of code. This
> > patch moves most of its contents into an external function. It
> > saves anywhere between 500 and 2500 bytes of text depending on the
> > configuration.
> > 
> > The function returns with an altered stackpointer.
> > 
> > Dwarf2-annotations are most probably wrong or missing.
> > 
> > There is a comment in the original code about saving rbp twice, but
> > I don't understand what the code tries to do. First of all, the
> > second copy of rbp is written below the stack.
> This is not for the stack, but to keep the registers as the pt_regs
> struct
> expects them. We'll be casting this structure later, and not doing that
> can lead to bogus code, whenever we cast regs->bp.
> 
> > Second, if the current
> > stack is already the irqstack, this second copy is overwritten. Third,
> > as far as I can tell, ebp should not be saved in pt_regs at all at
> > this stage as it is 'preserved' due to the C calling conventions. So
> > I left this second copy out and everything seems to work fine. If it
> > wouldn't, all exceptions and NMIs would be dangerous anyhow, as far
> > as I can see.
> Try testing with a kernel with CONFIG_FRAME_POINTER turned on.

Hi Glauber,

Thanks for your reply, but I'm afraid I still don't see why this
second copy is needed.

A CONFIG_FRAME_POINTER configuration seems to be working fine. Of
course regs->bp will give a bogus value, but so will r12, r13,
r14, r15, and rbx. However, if you have CONFIG_FRAME_POINTER=y,
then rbp can be trusted to be used as a framepointer... so one
should get it directly from the registers, not from regs->bp.

Could you give me a configuration that fails, and describe what
goes wrong? Probably the right fix is not to use regs->bp.

Greetings,
    Alexander

> >
> > Signed-off-by: Alexander van Heukelum <heukelum@...tmail.fm>
> > Cc: Glauber Costa <gcosta@...hat.com>
-- 
  Alexander van Heukelum
  heukelum@...tmail.fm

-- 
http://www.fastmail.fm - mmm... Fastmail...

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