On Thu, Apr 23, 2015 at 8:49 AM, Borislav Petkov wrote:
> On Thu, Apr 23, 2015 at 08:41:15AM -0700, Andy Lutomirski wrote:
>> I was rather vague there. Let me try again:
>>
>> If anyone in the AMD camp really cared, we could add a new bug flag
>> X86_BUG_SYSRET_NEEDS_CANONICAL_RCX and set it on I
On Thu, Apr 23, 2015 at 08:41:15AM -0700, Andy Lutomirski wrote:
> I was rather vague there. Let me try again:
>
> If anyone in the AMD camp really cared, we could add a new bug flag
> X86_BUG_SYSRET_NEEDS_CANONICAL_RCX and set it on Intel chips only, so
> we could use alternatives to patch out t
On Thu, Apr 23, 2015 at 8:10 AM, Borislav Petkov wrote:
> On Tue, Apr 21, 2015 at 11:08:42AM -0700, Andy Lutomirski wrote:
>> I'll take a full implementation of what Intel says over probably
>> unmeasurable performance. If anyone in the AMD camp really cared, we
>> could add X86_BUG_SYSRET_NEEDS_
On Tue, Apr 21, 2015 at 11:08:42AM -0700, Andy Lutomirski wrote:
> I'll take a full implementation of what Intel says over probably
> unmeasurable performance. If anyone in the AMD camp really cared, we
> could add X86_BUG_SYSRET_NEEDS_CANONICAL_RCX and use alternatives to
> patch this out on AMD.
On Tue, Apr 21, 2015 at 9:27 AM, Denys Vlasenko wrote:
> This change makes the check exact (no more false positives
> on "negative" addresses).
Acked-by: Andy Lutomirski
I'll take a full implementation of what Intel says over probably
unmeasurable performance. If anyone in the AMD camp really
* Denys Vlasenko wrote:
> On 03/26/2015 01:42 PM, Denys Vlasenko wrote:
> > This change makes the check exact (no more false positives
> > on kernel addresses).
> >
> > It isn't really important to be fully correct here -
> > almost all addresses we'll ever see will be userspace ones,
> > but O
On 03/26/2015 01:42 PM, Denys Vlasenko wrote:
> This change makes the check exact (no more false positives
> on kernel addresses).
>
> It isn't really important to be fully correct here -
> almost all addresses we'll ever see will be userspace ones,
> but OTOH it looks to be cheap enough:
> the ne
On 03/31/2015 07:08 PM, Andy Lutomirski wrote:
> On Tue, Mar 31, 2015 at 9:43 AM, Ingo Molnar wrote:
>>
>> * Denys Vlasenko wrote:
>>
I guess they could optimize it by adding a single "I am a modern
OS executing regular userspace" flag to the descriptor [or
expressing the same as a
On Tue, Mar 31, 2015 at 9:43 AM, Ingo Molnar wrote:
>
> * Denys Vlasenko wrote:
>
>> > I guess they could optimize it by adding a single "I am a modern
>> > OS executing regular userspace" flag to the descriptor [or
>> > expressing the same as a separate instruction], to avoid all that
>> > legac
* Denys Vlasenko wrote:
> > I guess they could optimize it by adding a single "I am a modern
> > OS executing regular userspace" flag to the descriptor [or
> > expressing the same as a separate instruction], to avoid all that
> > legacy crap that won't trigger on like 99.99% of systems ..
On Mon, Mar 30, 2015 at 7:30 AM, Andy Lutomirski wrote:
> On Mon, Mar 30, 2015 at 7:27 AM, Denys Vlasenko wrote:
>> On 03/26/2015 07:45 PM, Andy Lutomirski wrote:
>>> On Thu, Mar 26, 2015 at 5:42 AM, Denys Vlasenko wrote:
This change makes the check exact (no more false positives
on ke
On Mon, Mar 30, 2015 at 7:27 AM, Denys Vlasenko wrote:
> On 03/26/2015 07:45 PM, Andy Lutomirski wrote:
>> On Thu, Mar 26, 2015 at 5:42 AM, Denys Vlasenko wrote:
>>> This change makes the check exact (no more false positives
>>> on kernel addresses).
>>>
>>> It isn't really important to be fully
On 03/26/2015 07:45 PM, Andy Lutomirski wrote:
> On Thu, Mar 26, 2015 at 5:42 AM, Denys Vlasenko wrote:
>> This change makes the check exact (no more false positives
>> on kernel addresses).
>>
>> It isn't really important to be fully correct here -
>> almost all addresses we'll ever see will be u
On Sun, Mar 29, 2015 at 11:12 PM, Andy Lutomirski wrote:
> On Sun, Mar 29, 2015 at 12:36 PM, Denys Vlasenko
> wrote:
>> The instruction would need a differentiator whether returned-to code
>> is 64-bit or 32-bit.
>> Then it probably can use the same approach SYSRET{O,L} uses:
>> with REX.W, retur
On Sun, Mar 29, 2015 at 12:36 PM, Denys Vlasenko
wrote:
> On Sat, Mar 28, 2015 at 10:11 AM, Ingo Molnar wrote:
>>> >> $ ./timing_test64 iret
>>> >> 1 loops in 0.00344s = 343.90 nsec/loop for iret
>>> >> 10 loops in 0.01890s = 188.97 nsec/loop for iret
>>> >> 100 loops in 0.08228s = 82
On Sat, Mar 28, 2015 at 10:11 AM, Ingo Molnar wrote:
>> >> $ ./timing_test64 iret
>> >> 1 loops in 0.00344s = 343.90 nsec/loop for iret
>> >> 10 loops in 0.01890s = 188.97 nsec/loop for iret
>> >> 100 loops in 0.08228s = 82.28 nsec/loop for iret
>> >> 1000 loops in 0.77910s = 77.91
* Denys Vlasenko wrote:
> On 03/27/2015 01:16 PM, Ingo Molnar wrote:
> >>> Indeed, an IRET ought to be pretty cheap for same-ring interrupt
> >>> returns in any case.
> >>
> >> Unfortunately, it is not. Try attached program.
> >>
> >> On this CPU, 1 ns ~= 3 cycles.
> >>
> >> $ ./timing_test64 c
On Fri, Mar 27, 2015 at 4:31 AM, Ingo Molnar wrote:
>
> * Brian Gerst wrote:
>
>> On Thu, Mar 26, 2015 at 8:42 AM, Denys Vlasenko wrote:
>> > This change makes the check exact (no more false positives
>> > on kernel addresses).
>> >
>> > It isn't really important to be fully correct here -
>> >
On 03/27/2015 01:16 PM, Ingo Molnar wrote:
>>> Indeed, an IRET ought to be pretty cheap for same-ring interrupt
>>> returns in any case.
>>
>> Unfortunately, it is not. Try attached program.
>>
>> On this CPU, 1 ns ~= 3 cycles.
>>
>> $ ./timing_test64 callret
>> 1 loops in 0.8s = 7.87 nsec
* Denys Vlasenko wrote:
> > Indeed, an IRET ought to be pretty cheap for same-ring interrupt
> > returns in any case.
>
> Unfortunately, it is not. Try attached program.
>
> On this CPU, 1 ns ~= 3 cycles.
>
> $ ./timing_test64 callret
> 1 loops in 0.8s = 7.87 nsec/loop for callret
>
On 03/27/2015 12:34 PM, Ingo Molnar wrote:
>
> * Brian Gerst wrote:
>
>>> Btw., there's a neat trick we could do: in the HLT, MWAIT and
>>> ACPI-idle code we could attempt to set up RCX to match RIP, to
>>> trigger this optimization in the common 'irq interrupted the idle
>>> task' case?
>>
>
* Brian Gerst wrote:
> > Btw., there's a neat trick we could do: in the HLT, MWAIT and
> > ACPI-idle code we could attempt to set up RCX to match RIP, to
> > trigger this optimization in the common 'irq interrupted the idle
> > task' case?
>
> sysret only returns to CPL3.
Indeed, an IRET ou
* Brian Gerst wrote:
> On Thu, Mar 26, 2015 at 8:42 AM, Denys Vlasenko wrote:
> > This change makes the check exact (no more false positives
> > on kernel addresses).
> >
> > It isn't really important to be fully correct here -
> > almost all addresses we'll ever see will be userspace ones,
> >
On Fri, Mar 27, 2015 at 7:17 AM, Ingo Molnar wrote:
>
> * Denys Vlasenko wrote:
>
>> On 03/27/2015 09:11 AM, Ingo Molnar wrote:
>> >
>> > * Denys Vlasenko wrote:
>> >
>> >> This change makes the check exact (no more false positives
>> >> on kernel addresses).
>> >>
>> >> It isn't really importan
On Thu, Mar 26, 2015 at 8:42 AM, Denys Vlasenko wrote:
> This change makes the check exact (no more false positives
> on kernel addresses).
>
> It isn't really important to be fully correct here -
> almost all addresses we'll ever see will be userspace ones,
> but OTOH it looks to be cheap enough:
* Denys Vlasenko wrote:
> On 03/27/2015 09:11 AM, Ingo Molnar wrote:
> >
> > * Denys Vlasenko wrote:
> >
> >> This change makes the check exact (no more false positives
> >> on kernel addresses).
> >>
> >> It isn't really important to be fully correct here -
> >> almost all addresses we'll ev
On 03/27/2015 09:11 AM, Ingo Molnar wrote:
>
> * Denys Vlasenko wrote:
>
>> This change makes the check exact (no more false positives
>> on kernel addresses).
>>
>> It isn't really important to be fully correct here -
>> almost all addresses we'll ever see will be userspace ones,
>> but OTOH it
On Thu, Mar 26, 2015 at 11:45:19AM -0700, Andy Lutomirski wrote:
> I suspect that the two added ALU ops are free for all practical
> purposes, and the performance of this path isn't *that* critical.
>
> If anyone is running with vsyscall=native because they need the
> performance, then this would
* Denys Vlasenko wrote:
> This change makes the check exact (no more false positives
> on kernel addresses).
>
> It isn't really important to be fully correct here -
> almost all addresses we'll ever see will be userspace ones,
> but OTOH it looks to be cheap enough:
> the new code uses two mor
On Thu, Mar 26, 2015 at 5:42 AM, Denys Vlasenko wrote:
> This change makes the check exact (no more false positives
> on kernel addresses).
>
> It isn't really important to be fully correct here -
> almost all addresses we'll ever see will be userspace ones,
> but OTOH it looks to be cheap enough:
30 matches
Mail list logo
