On 07/14/2014 07:46 PM, Andy Lutomirski wrote:
>
> On espfix-less kernels (Xen and non-Xen), 16-bit CS w/ 16-bit SS
> always fails. Native (32-bit or 64-bit, according to the binary) CS
> with 16-bit SS fails for sigreturn_32, but passes for sigreturn_64. I
> find this somewhat odd. Native ss
On Mon, Jul 14, 2014 at 7:46 PM, Andy Lutomirski wrote:
> On Mon, Jul 14, 2014 at 3:23 PM, H. Peter Anvin wrote:
>> On 07/14/2014 02:35 PM, Andy Lutomirski wrote:
>>> Presumably the problem is here:
>>>
>>> ENTRY(xen_iret)
>>> pushq $0
>>> 1:jmp hypercall_iret
>>> ENDPATCH(xen_iret)
>>>
On Mon, Jul 14, 2014 at 3:23 PM, H. Peter Anvin wrote:
> On 07/14/2014 02:35 PM, Andy Lutomirski wrote:
>> Presumably the problem is here:
>>
>> ENTRY(xen_iret)
>> pushq $0
>> 1:jmp hypercall_iret
>> ENDPATCH(xen_iret)
>>
>> This seems rather unlikely to work on the espfix stack.
>>
>>
On 07/14/2014 02:35 PM, Andy Lutomirski wrote:
> Presumably the problem is here:
>
> ENTRY(xen_iret)
> pushq $0
> 1:jmp hypercall_iret
> ENDPATCH(xen_iret)
>
> This seems rather unlikely to work on the espfix stack.
>
> Maybe espfix64 should be disabled when running on Xen and Xen
On Mon, Jul 14, 2014 at 2:31 PM, Andy Lutomirski wrote:
> I'm now rather confused.
>
> On Xen 64-bit, AFAICS, syscall handlers run with CS = 0xe033. I think
> that Xen is somehow fixing up traps that came from "kernel" mode to
> show CS = 0xe030, which is an impossible selector value (unless
I'm now rather confused.
On Xen 64-bit, AFAICS, syscall handlers run with CS = 0xe033. I think
that Xen is somehow fixing up traps that came from "kernel" mode to
show CS = 0xe030, which is an impossible selector value (unless that
segment is conforming) to keep user_mode_vm happy.
I'm running
On Mon, Jul 14, 2014 at 10:11 AM, Andy Lutomirski wrote:
> On Mon, Jul 14, 2014 at 10:04 AM, H. Peter Anvin wrote:
>> On 07/09/2014 04:17 PM, Andy Lutomirski wrote:
>>> This part in __do_double_fault looks fishy:
>>>
>>> cmpl $__KERNEL_CS,CS(%rdi)
>>> jne do_double_fault
>>>
>>>
On Mon, Jul 14, 2014 at 10:04 AM, H. Peter Anvin wrote:
> On 07/09/2014 04:17 PM, Andy Lutomirski wrote:
>> This part in __do_double_fault looks fishy:
>>
>> cmpl $__KERNEL_CS,CS(%rdi)
>> jne do_double_fault
>>
>> Shouldn't that be:
>>
>> test $3,CS(%rdi)
>> jnz do_double_fault
>>
On 07/09/2014 04:17 PM, Andy Lutomirski wrote:
> This part in __do_double_fault looks fishy:
>
> cmpl $__KERNEL_CS,CS(%rdi)
> jne do_double_fault
>
> Shouldn't that be:
>
> test $3,CS(%rdi)
> jnz do_double_fault
>
No, it should be fine. The *only* case where we need to do the
On Wed, Jul 09, 2014 at 04:17:57PM -0700, Andy Lutomirski wrote:
> This part in __do_double_fault looks fishy:
>
> cmpl $__KERNEL_CS,CS(%rdi)
> jne do_double_fault
>
> Shouldn't that be:
>
> test $3,CS(%rdi)
> jnz do_double_fault
>
Let me rope in David, who was playing with
On Wed, Jul 09, 2014 at 04:17:57PM -0700, Andy Lutomirski wrote:
This part in __do_double_fault looks fishy:
cmpl $__KERNEL_CS,CS(%rdi)
jne do_double_fault
Shouldn't that be:
test $3,CS(%rdi)
jnz do_double_fault
Let me rope in David, who was playing with that
On 07/09/2014 04:17 PM, Andy Lutomirski wrote:
This part in __do_double_fault looks fishy:
cmpl $__KERNEL_CS,CS(%rdi)
jne do_double_fault
Shouldn't that be:
test $3,CS(%rdi)
jnz do_double_fault
No, it should be fine. The *only* case where we need to do the espfix
On Mon, Jul 14, 2014 at 10:04 AM, H. Peter Anvin h...@zytor.com wrote:
On 07/09/2014 04:17 PM, Andy Lutomirski wrote:
This part in __do_double_fault looks fishy:
cmpl $__KERNEL_CS,CS(%rdi)
jne do_double_fault
Shouldn't that be:
test $3,CS(%rdi)
jnz do_double_fault
No,
On Mon, Jul 14, 2014 at 10:11 AM, Andy Lutomirski l...@amacapital.net wrote:
On Mon, Jul 14, 2014 at 10:04 AM, H. Peter Anvin h...@zytor.com wrote:
On 07/09/2014 04:17 PM, Andy Lutomirski wrote:
This part in __do_double_fault looks fishy:
cmpl $__KERNEL_CS,CS(%rdi)
jne
I'm now rather confused.
On Xen 64-bit, AFAICS, syscall handlers run with CS = 0xe033. I think
that Xen is somehow fixing up traps that came from kernel mode to
show CS = 0xe030, which is an impossible selector value (unless that
segment is conforming) to keep user_mode_vm happy.
I'm running
On Mon, Jul 14, 2014 at 2:31 PM, Andy Lutomirski l...@amacapital.net wrote:
I'm now rather confused.
On Xen 64-bit, AFAICS, syscall handlers run with CS = 0xe033. I think
that Xen is somehow fixing up traps that came from kernel mode to
show CS = 0xe030, which is an impossible selector value
On 07/14/2014 02:35 PM, Andy Lutomirski wrote:
Presumably the problem is here:
ENTRY(xen_iret)
pushq $0
1:jmp hypercall_iret
ENDPATCH(xen_iret)
This seems rather unlikely to work on the espfix stack.
Maybe espfix64 should be disabled when running on Xen and Xen should
On Mon, Jul 14, 2014 at 3:23 PM, H. Peter Anvin h...@zytor.com wrote:
On 07/14/2014 02:35 PM, Andy Lutomirski wrote:
Presumably the problem is here:
ENTRY(xen_iret)
pushq $0
1:jmp hypercall_iret
ENDPATCH(xen_iret)
This seems rather unlikely to work on the espfix stack.
Maybe
On Mon, Jul 14, 2014 at 7:46 PM, Andy Lutomirski l...@amacapital.net wrote:
On Mon, Jul 14, 2014 at 3:23 PM, H. Peter Anvin h...@zytor.com wrote:
On 07/14/2014 02:35 PM, Andy Lutomirski wrote:
Presumably the problem is here:
ENTRY(xen_iret)
pushq $0
1:jmp hypercall_iret
On 07/14/2014 07:46 PM, Andy Lutomirski wrote:
On espfix-less kernels (Xen and non-Xen), 16-bit CS w/ 16-bit SS
always fails. Native (32-bit or 64-bit, according to the binary) CS
with 16-bit SS fails for sigreturn_32, but passes for sigreturn_64. I
find this somewhat odd. Native ss
This part in __do_double_fault looks fishy:
cmpl $__KERNEL_CS,CS(%rdi)
jne do_double_fault
Shouldn't that be:
test $3,CS(%rdi)
jnz do_double_fault
--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
This part in __do_double_fault looks fishy:
cmpl $__KERNEL_CS,CS(%rdi)
jne do_double_fault
Shouldn't that be:
test $3,CS(%rdi)
jnz do_double_fault
--Andy
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to
22 matches
Mail list logo
