linux-kernel - Re: [GIT PULL] x86/paravirt for v2.6.33

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:	Wed, 9 Dec 2009 10:38:51 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	"H. Peter Anvin" <hpa@...or.com>
cc:	Jeremy Fitzhardinge <jeremy@...p.org>, Ingo Molnar <mingo@...e.hu>,
	linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Hugh Dickens <hugh@...itas.com>
Subject: Re: [GIT PULL] x86/paravirt for v2.6.33

On Wed, 9 Dec 2009, H. Peter Anvin wrote:
> "Jeremy Fitzhardinge" <jeremy@...p.org> wrote:
> >
> >But I'm not sure I understand the objection to task_pt_regs(); is it 
> >considered deprecated?   This patch received quite a lot of discussion 
> >with no mention of it.  Should we consider all its uses as suspect?

I personally would be much happier without ever seeing a single 
task_pt_regs() call outside of pure ptrace() users (and quite frankly, 
even there I'd be happier if it was basically done once, and then 'struct 
pt_regs' being passed around as an argument as much as possible).

In the case of 'ptrace' we control the stack of the tracee. 

In other cases, we do _not_.

For example, think about us ever implementing 'tasklets' or async system 
calls in general. It's _very_ possible that we'd have a special stolen 
stack for them, and run the low-level system call function from that 
stack. Then something like task_pt_regs() migth very well do the wrong 
thing.

Now, I'm not saying that 'sys_iopl()' would ever be a valid target for 
async system calls, but I _am_ saying that system calls that depend on 
task_pt_regs() are fundamnetally fragile and broken, and have subtle 
interactions.

In contrast, if you make it very explicit that the system call gets passed 
a pointer to its pt_regs, then it still has all the same issues, but now 
it's not subtle any more - now it's explicitly encoded in the call 
sequence on both the caller and callee sides, and somebody doing tasklets 
would hopefully see that "oh, iopl() has that same special thing that 
fork/clone/vfork/execve has, and touches the stack frame register set 
explicitly".

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