On Tue, Aug 23, 2011 at 03:17:18AM +0100, Al Viro wrote:
> I have a very strong suspicion that I know what will turn out to be involved
> into that - the page eviction done by sys_brk(). Note that dirtying this
> sucker is really necessary - without *s = 0 it won't segfault at all. With
> it we
On 08/22/2011 01:03 AM, H. Peter Anvin wrote:
> On 08/21/2011 09:26 PM, Al Viro wrote:
>> On Sun, Aug 21, 2011 at 09:11:54PM -0700, H. Peter Anvin wrote:
lack of point - the *only* CPU where it would matter would be K6-2, IIRC,
and (again, IIRC) it had some differences in SYSCALL semantic
On Mon, 22 Aug 2011 23:38:43 +0200, Richard Weinberger wrote:
> Hi!
>
> UserModeLinux is using the arch specific module functions from
> arch/x86/kernel/module.c.
> On i386 this works perfectly fine but on x86_64 it causes problems.
>
> apply_relocate_add() assumes modules compiled with -mcmode
On Mon, Aug 22, 2011 at 06:59:48PM -0700, Linus Torvalds wrote:
> And the system call restart should actually work fine too, because at
> syscall entry we save %ebp *both* in the slot for ebp and ecx when we
> enter the first time. So the second time, we'll re-load the third
> argument from ebp ag
On Tue, Aug 23, 2011 at 02:13:12AM +0100, Al Viro wrote:
> *UGH*. OK,
> 1) I'm an idiot; int_ret_from_sys_call does *not* usually step on
> rbp (it's callee-saved). So normally ebp is left as is on the way out,
> which is why we don't see stuff getting buggered left, right and center.
>
On Mon, Aug 22, 2011 at 6:13 PM, Al Viro wrote:
>
> *UGH*. OK,
> 1) I'm an idiot; int_ret_from_sys_call does *not* usually step on
> rbp (it's callee-saved). So normally ebp is left as is on the way out,
> which is why we don't see stuff getting buggered left, right and center.
Check.
A
On 08/22/2011 06:16 PM, Andrew Lutomirski wrote:
>
> I suspect that very few things care whether syscall arguments get
> clobbered. The only way it would matter is if gcc reuses the argument
> in the ecx slot after an inlined syscall later in the same function.
> Any code that does that is alrea
On Aug 22, 2011 9:01 PM, "Al Viro" wrote:
>
> On Mon, Aug 22, 2011 at 05:22:07PM -0700, Linus Torvalds wrote:
>
> > You guys seem to positively _want_ to make this a bigger issue than it
> > is. As far as I can tell, nobody has ever even noticed this problem
> > before, and we already have a trivi
On Tue, Aug 23, 2011 at 02:01:46AM +0100, Al Viro wrote:
> now, what is going to happen to %ebp if we go through IRET path, for any
> reason? From my reading it appears that right after that IRET we'll have
> ebp containing arg6. I.e. what we'd pushed on stack. Now, popl %ebp
> will bring the s
On Mon, Aug 22, 2011 at 05:22:07PM -0700, Linus Torvalds wrote:
> You guys seem to positively _want_ to make this a bigger issue than it
> is. As far as I can tell, nobody has ever even noticed this problem
> before, and we already have a trivial fix ("don't do it then") for the
> case Al actually
On Mon, Aug 22, 2011 at 5:07 PM, H. Peter Anvin wrote:
>
> Checking for SYSCALL in the vdso is cheap... the only problem is if
> someone thinks that they can copy it out of the vdso and run it, having
> special-cased SYSENTER already, but not SYSCALL. The recent experience
> shows that that is ap
On 08/22/2011 05:03 PM, Al Viro wrote:
> On Mon, Aug 22, 2011 at 04:27:51PM -0700, Linus Torvalds wrote:
>
>> So I think the "let's fix the vdso case for sysenter" + "let's remove
>> the 32-bit syscall vdso" is the right solution. If somebody has
>> hardcoded syscall instructions, or generates the
On Tue, Aug 23, 2011 at 01:03:14AM +0100, Al Viro wrote:
> On Mon, Aug 22, 2011 at 04:27:51PM -0700, Linus Torvalds wrote:
>
> > So I think the "let's fix the vdso case for sysenter" + "let's remove
> > the 32-bit syscall vdso" is the right solution. If somebody has
> > hardcoded syscall instructi
On Mon, Aug 22, 2011 at 04:27:51PM -0700, Linus Torvalds wrote:
> So I think the "let's fix the vdso case for sysenter" + "let's remove
> the 32-bit syscall vdso" is the right solution. If somebody has
> hardcoded syscall instructions, or generates them dynamically with
> some JIT, that's their pr
On 08/22/2011 04:27 PM, Linus Torvalds wrote:
> On Mon, Aug 22, 2011 at 3:04 PM, H. Peter Anvin wrote:
>>
>> However, we could just issue a SIGILL or SIGSEGV at this point; the same
>> way we would if we got an #UD or #GP fault; SIGILL/#UD would be
>> consistent with Intel CPUs here.
>
> Consider
On Mon, Aug 22, 2011 at 3:04 PM, H. Peter Anvin wrote:
>
> However, we could just issue a SIGILL or SIGSEGV at this point; the same
> way we would if we got an #UD or #GP fault; SIGILL/#UD would be
> consistent with Intel CPUs here.
Considering that this is not a remotely new issue, and that it h
On 08/22/2011 02:52 PM, Andrew Lutomirski wrote:
>
> Even if it's ok, we still have to do *something* in the cstar entry
> point -- I don't think there's any way to turn SYSCALL in
> compatibility mode but leave it enabled in long mode. So if we're
> planning on killing off SYSCALL from outside t
On Mon, Aug 22, 2011 at 4:11 PM, H. Peter Anvin wrote:
> On 08/22/2011 01:05 PM, Linus Torvalds wrote:
>> On Mon, Aug 22, 2011 at 8:13 AM, Al Viro wrote:
>>>
>>> In __kernel_vsyscall() the problem is possible to deal with; there we
>>> control
>>> the code around that sucker. It's SYSCALL in 32
Hi!
UserModeLinux is using the arch specific module functions from
arch/x86/kernel/module.c.
On i386 this works perfectly fine but on x86_64 it causes problems.
apply_relocate_add() assumes modules compiled with -mcmodel=kernel
because the kernel lives in the negative 2GiB of the address space.
On 08/22/2011 01:05 PM, Linus Torvalds wrote:
> On Mon, Aug 22, 2011 at 8:13 AM, Al Viro wrote:
>>
>> In __kernel_vsyscall() the problem is possible to deal with; there we control
>> the code around that sucker. It's SYSCALL in 32bit binary outside of
>> vdso32 that causes real PITA...
>
> I jus
On Mon, Aug 22, 2011 at 8:13 AM, Al Viro wrote:
>
> In __kernel_vsyscall() the problem is possible to deal with; there we control
> the code around that sucker. It's SYSCALL in 32bit binary outside of
> vdso32 that causes real PITA...
I just checked. 'syscall' (at least on x86-64) is definitely
On Mon, Aug 22, 2011 at 09:34:27AM -0400, Andrew Lutomirski wrote:
> On Mon, Aug 22, 2011 at 5:53 AM, Ingo Molnar wrote:
> >
> > * H. Peter Anvin wrote:
> >
> >> Borislav,
> >>
> >> We're tracking down an issue with the way system call arguments are
> >> handled on 32 bits. We have a solution fo
On Mon, Aug 22, 2011 at 04:40:51PM +0200, Borislav Petkov wrote:
> Just to make sure I'm grokking this correctly - we want to use int $0x80
> only for the SYSCALL variant in __kernel_vsyscall, right? Not for all
> 32-bit syscalls on a 64-bit kernel.
Um... The problem is, syscall restart with SYS
On Mon, Aug 22, 2011 at 5:53 AM, Ingo Molnar wrote:
>
> * H. Peter Anvin wrote:
>
>> Borislav,
>>
>> We're tracking down an issue with the way system call arguments are
>> handled on 32 bits. We have a solution for SYSENTER but not
>> SYSCALL; fixing SYSCALL "properly" appears to be very difficu
* H. Peter Anvin wrote:
> Borislav,
>
> We're tracking down an issue with the way system call arguments are
> handled on 32 bits. We have a solution for SYSENTER but not
> SYSCALL; fixing SYSCALL "properly" appears to be very difficult at
> best.
>
> So the question is: how much overhead w
25 matches
Mail list logo
