On 05/01/2014 03:18 PM, Andi Kleen wrote:
>> I haven't looked through the flows (I'm at LCE so I have limited screen
>> bandwidth) to see how that would be handled in this case, but in the
>> general paranoid case it comes down to the fact that in this particular
>> subcase we don't necessarily
> I haven't looked through the flows (I'm at LCE so I have limited screen
> bandwidth) to see how that would be handled in this case, but in the
> general paranoid case it comes down to the fact that in this particular
> subcase we don't necessarily know exactly how many SWAPGS are between us
>
On Thu, May 1, 2014 at 2:58 PM, H. Peter Anvin wrote:
> On 05/01/2014 02:15 PM, Andi Kleen wrote:
>>> If usergs == kernelgs, then ebx will always be 1 and we'll never end
>>> up in paranoid_userspace.
>>
>> You may miss a reschedule in this obscure case. It shouldn't really
>> happen because
On 05/01/2014 02:15 PM, Andi Kleen wrote:
>> If usergs == kernelgs, then ebx will always be 1 and we'll never end
>> up in paranoid_userspace.
>
> You may miss a reschedule in this obscure case. It shouldn't really
> happen because loading a kernel pointer is not useful for user space.
>
>
On Thu, May 1, 2014 at 2:51 PM, Andi Kleen wrote:
>> Allowing userspace to prevent itself from being rescheduled by loading
>> something strange into gsbase seems unfortunate.
>
> The timer tick will eventually catch it, so any delay is tightly
> bounded.
>
What about NO_HZ_FULL?
> Also still
> Allowing userspace to prevent itself from being rescheduled by loading
> something strange into gsbase seems unfortunate.
The timer tick will eventually catch it, so any delay is tightly
bounded.
Also still gets rescheduled most of the time, just not when a paranoid
exception handler is
On Thu, May 1, 2014 at 2:15 PM, Andi Kleen wrote:
>> If usergs == kernelgs, then ebx will always be 1 and we'll never end
>> up in paranoid_userspace.
>
> You may miss a reschedule in this obscure case. It shouldn't really
> happen because loading a kernel pointer is not useful for user space.
>
> If usergs == kernelgs, then ebx will always be 1 and we'll never end
> up in paranoid_userspace.
You may miss a reschedule in this obscure case. It shouldn't really
happen because loading a kernel pointer is not useful for user space.
Doesn't seem like a real issue to me.
We only happen need
If usergs == kernelgs, then ebx will always be 1 and we'll never end
up in paranoid_userspace.
You may miss a reschedule in this obscure case. It shouldn't really
happen because loading a kernel pointer is not useful for user space.
Doesn't seem like a real issue to me.
We only happen need to
On Thu, May 1, 2014 at 2:15 PM, Andi Kleen a...@firstfloor.org wrote:
If usergs == kernelgs, then ebx will always be 1 and we'll never end
up in paranoid_userspace.
You may miss a reschedule in this obscure case. It shouldn't really
happen because loading a kernel pointer is not useful for
Allowing userspace to prevent itself from being rescheduled by loading
something strange into gsbase seems unfortunate.
The timer tick will eventually catch it, so any delay is tightly
bounded.
Also still gets rescheduled most of the time, just not when a paranoid
exception handler is
On Thu, May 1, 2014 at 2:51 PM, Andi Kleen a...@firstfloor.org wrote:
Allowing userspace to prevent itself from being rescheduled by loading
something strange into gsbase seems unfortunate.
The timer tick will eventually catch it, so any delay is tightly
bounded.
What about NO_HZ_FULL?
On 05/01/2014 02:15 PM, Andi Kleen wrote:
If usergs == kernelgs, then ebx will always be 1 and we'll never end
up in paranoid_userspace.
You may miss a reschedule in this obscure case. It shouldn't really
happen because loading a kernel pointer is not useful for user space.
Doesn't seem
On Thu, May 1, 2014 at 2:58 PM, H. Peter Anvin h...@zytor.com wrote:
On 05/01/2014 02:15 PM, Andi Kleen wrote:
If usergs == kernelgs, then ebx will always be 1 and we'll never end
up in paranoid_userspace.
You may miss a reschedule in this obscure case. It shouldn't really
happen because
I haven't looked through the flows (I'm at LCE so I have limited screen
bandwidth) to see how that would be handled in this case, but in the
general paranoid case it comes down to the fact that in this particular
subcase we don't necessarily know exactly how many SWAPGS are between us
and
On 05/01/2014 03:18 PM, Andi Kleen wrote:
I haven't looked through the flows (I'm at LCE so I have limited screen
bandwidth) to see how that would be handled in this case, but in the
general paranoid case it comes down to the fact that in this particular
subcase we don't necessarily know
On Wed, Apr 30, 2014 at 4:44 PM, Andy Lutomirski wrote:
> On Tue, Apr 29, 2014 at 9:52 PM, H. Peter Anvin wrote:
>> On 04/29/2014 04:39 PM, Andi Kleen wrote:
Case 3 is annoying. If nothing tries to change the user gs base, then
everything is okay because the user gs base and the
On Tue, Apr 29, 2014 at 9:52 PM, H. Peter Anvin wrote:
> On 04/29/2014 04:39 PM, Andi Kleen wrote:
>>> Case 3 is annoying. If nothing tries to change the user gs base, then
>>> everything is okay because the user gs base and the kernel gs bases are
>>> equal. But if something does try to change
On Tue, Apr 29, 2014 at 9:52 PM, H. Peter Anvin h...@zytor.com wrote:
On 04/29/2014 04:39 PM, Andi Kleen wrote:
Case 3 is annoying. If nothing tries to change the user gs base, then
everything is okay because the user gs base and the kernel gs bases are
equal. But if something does try to
On Wed, Apr 30, 2014 at 4:44 PM, Andy Lutomirski l...@amacapital.net wrote:
On Tue, Apr 29, 2014 at 9:52 PM, H. Peter Anvin h...@zytor.com wrote:
On 04/29/2014 04:39 PM, Andi Kleen wrote:
Case 3 is annoying. If nothing tries to change the user gs base, then
everything is okay because the user
On 04/29/2014 09:52 PM, H. Peter Anvin wrote:
>
> It matters -- greatly -- if (and only if) we can enter the kernel with
> usergs == kernelgs and then want to change usergs inside a paranoid
> routine. At that point we risk being upside down, which basically means
> we're rooted.
>
> However, I
On 04/29/2014 04:39 PM, Andi Kleen wrote:
>> Case 3 is annoying. If nothing tries to change the user gs base, then
>> everything is okay because the user gs base and the kernel gs bases are
>> equal. But if something does try to change the user gs base, then it
>> will accidentally change the
> Case 3 is annoying. If nothing tries to change the user gs base, then
> everything is okay because the user gs base and the kernel gs bases are
> equal. But if something does try to change the user gs base, then it
> will accidentally change the kernel gs base instead.
It doesn't really
On 04/28/2014 03:12 PM, Andi Kleen wrote:
> From: Andi Kleen
>
> IvyBridge added new instructions to directly write the fs and gs
> 64bit base registers. Previously this had to be done with a system
> call to write to MSRs. The main use case is fast user space threading
> and switching the fs/gs
On 04/28/2014 03:12 PM, Andi Kleen wrote:
From: Andi Kleen a...@linux.intel.com
IvyBridge added new instructions to directly write the fs and gs
64bit base registers. Previously this had to be done with a system
call to write to MSRs. The main use case is fast user space threading
and
Case 3 is annoying. If nothing tries to change the user gs base, then
everything is okay because the user gs base and the kernel gs bases are
equal. But if something does try to change the user gs base, then it
will accidentally change the kernel gs base instead.
It doesn't really matter,
On 04/29/2014 04:39 PM, Andi Kleen wrote:
Case 3 is annoying. If nothing tries to change the user gs base, then
everything is okay because the user gs base and the kernel gs bases are
equal. But if something does try to change the user gs base, then it
will accidentally change the kernel gs
On 04/29/2014 09:52 PM, H. Peter Anvin wrote:
It matters -- greatly -- if (and only if) we can enter the kernel with
usergs == kernelgs and then want to change usergs inside a paranoid
routine. At that point we risk being upside down, which basically means
we're rooted.
However, I
From: Andi Kleen
IvyBridge added new instructions to directly write the fs and gs
64bit base registers. Previously this had to be done with a system
call to write to MSRs. The main use case is fast user space threading
and switching the fs/gs registers quickly there.
The instructions are opt-in
From: Andi Kleen a...@linux.intel.com
IvyBridge added new instructions to directly write the fs and gs
64bit base registers. Previously this had to be done with a system
call to write to MSRs. The main use case is fast user space threading
and switching the fs/gs registers quickly there.
The
30 matches
Mail list logo
