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

Date:	Wed, 09 Dec 2009 10:29:30 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Jeremy Fitzhardinge <jeremy@...p.org>, Ingo Molnar <mingo@...e.hu>
CC:	Linus Torvalds <torvalds@...ux-foundation.org>,
	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

Linus clearly prefers the style with pt_regs passed on the stack as the sole form.  Since we *have* to use that form for things like clone(), it makes sense to use it as the only form.

For what it's worth I did look at this when the patch first came up; it does make the individual patch a fair bit uglier, but I can understand Linus' consistency argument.

As far as I know, we don't allow any system calls from inside v86 mode.


	-hpa

"Jeremy Fitzhardinge" <jeremy@...p.org> wrote:

>On 12/08/09 23:36, Ingo Molnar wrote:
>>> The old version that actually passed the stack frame was better. Why
>>> pick the inferior version?
>>>      
>> Yeah, agreed. I missed that detail.
>>    
>
>Which detail is that?  The whole patch? ;)
>
>> Jeremy, mind sending a patch that updates this code to use the less
>> obfuscated 32-bit version, not the 64-bit version? (a delta patch
>> against tip:master would be nice, as there's a fair amount of testing in
>> the unification change itself already, which we dont want to discard.)
>>    
>
>Sure.
>
>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?
>
>Would it be better to have something similar which just returns a 
>pointer to the saved [re]flags, since that's all we care about?  That 
>should be easier to make robust against
>
>     J

--
Sent from my mobile phone. Please excuse any lack of formatting.