On Fri, Oct 12, 2018 at 8:02 AM Alan Cox wrote:
>
> > My understanding is that the standard “breadcrumb” is that a cache line is
> > fetched into L1D, and that the cacheline in question will go into L1D even
> > if it was previously not cached at all. So flushing L1D will cause the
> > timing f
On Fri, Oct 12, 2018 at 5:03 PM Alan Cox wrote:
>
> > My understanding is that the standard “breadcrumb” is that a cache line is
> > fetched into L1D, and that the cacheline in question will go into L1D even
> > if it was previously not cached at all. So flushing L1D will cause the
> > timing f
> My understanding is that the standard “breadcrumb” is that a cache line is
> fetched into L1D, and that the cacheline in question will go into L1D even if
> it was previously not cached at all. So flushing L1D will cause the timing
> from a probe to be different, but the breadcrumb is still th
On Oct 12, 2018, at 7:25 AM, Alan Cox wrote:
>> But this really needs to be clarified. Alan said that a bunch of the
>> "yet another Spectre variant" attacks would have been mitigated by
>> this patch. An explanation of *how* would be in order.
>
> Today you have the situation where somethi
On Fri, Oct 12, 2018 at 2:26 PM Jann Horn wrote:
>
> On Fri, Oct 12, 2018 at 11:41 AM Samuel Neves wrote:
> >
> > On Thu, Oct 11, 2018 at 8:25 PM Andy Lutomirski wrote:
> > > What exactly is this trying to protect against? And how many cycles
> > > should we expect L1D_FLUSH to take?
> >
> > As
> But this really needs to be clarified. Alan said that a bunch of the
> "yet another Spectre variant" attacks would have been mitigated by
> this patch. An explanation of *how* would be in order.
Today you have the situation where something creates a speculative
disclosure gadget. So we run aro
On Fri, Oct 12, 2018 at 11:41 AM Samuel Neves wrote:
>
> On Thu, Oct 11, 2018 at 8:25 PM Andy Lutomirski wrote:
> > What exactly is this trying to protect against? And how many cycles
> > should we expect L1D_FLUSH to take?
>
> As far as I could measure, I got 1660 cycles per wrmsr 0x10b, 0x1 on
On Thu, Oct 11, 2018 at 8:25 PM Andy Lutomirski wrote:
> What exactly is this trying to protect against? And how many cycles
> should we expect L1D_FLUSH to take?
As far as I could measure, I got 1660 cycles per wrmsr 0x10b, 0x1 on a
Skylake chip, and 1220 cycles on a Skylake-SP.
On Thu, 11 Oct 2018, Kristen C Accardi wrote:
> On Thu, 2018-10-11 at 13:55 -0700, Kees Cook wrote:
> > I think this looks like a good idea. It might be worth adding a
> > comment about the checks to explain why those errors are whitelisted.
> > It's a cheap and effective mitigation for "unknown fu
On Thu, 11 Oct 2018, Jann Horn wrote:
> On Thu, Oct 11, 2018 at 10:56 PM Kees Cook wrote:
> > Seems like just changing this with "ax == 0" into "ax >= 0" would solve
> > that?
>
> As spender points out on twitter
> (https://twitter.com/grsecurity/status/1050497259937370118 - thanks,
> spender!),
On Thu, 11 Oct 2018, Kees Cook wrote:
> On Thu, Oct 11, 2018 at 1:48 PM, Andy Lutomirski wrote:
> > On Thu, Oct 11, 2018 at 11:55 AM Kristen Carlson Accardi
> >> +__visible inline void l1_cache_flush(struct pt_regs *regs)
> >> +{
> >> + if (IS_ENABLED(CONFIG_SYSCALL_FLUSH) &&
> >> +
On Thu, Oct 11, 2018 at 11:17 PM Andy Lutomirski wrote:
> On Thu, Oct 11, 2018 at 1:55 PM Kees Cook wrote:
> > On Thu, Oct 11, 2018 at 1:48 PM, Andy Lutomirski wrote:
> > > On Thu, Oct 11, 2018 at 11:55 AM Kristen Carlson Accardi
> > > wrote:
> > >>
> > >> This patch aims to make it harder to p
On Thu, Oct 11, 2018 at 10:56 PM Kees Cook wrote:
> On Thu, Oct 11, 2018 at 1:48 PM, Andy Lutomirski wrote:
> > On Thu, Oct 11, 2018 at 11:55 AM Kristen Carlson Accardi
> > wrote:
> >>
> >> This patch aims to make it harder to perform cache timing attacks on data
> >> left behind by system calls
On Thu, 2018-10-11 at 13:55 -0700, Kees Cook wrote:
> On Thu, Oct 11, 2018 at 1:48 PM, Andy Lutomirski
> wrote:
> > On Thu, Oct 11, 2018 at 11:55 AM Kristen Carlson Accardi
> > wrote:
> > >
> > > This patch aims to make it harder to perform cache timing attacks
> > > on data
> > > left behind by
On Thu, Oct 11, 2018 at 1:55 PM Kees Cook wrote:
>
> On Thu, Oct 11, 2018 at 1:48 PM, Andy Lutomirski wrote:
> > On Thu, Oct 11, 2018 at 11:55 AM Kristen Carlson Accardi
> > wrote:
> >>
> >> This patch aims to make it harder to perform cache timing attacks on data
> >> left behind by system call
On Thu, Oct 11, 2018 at 1:48 PM, Andy Lutomirski wrote:
> On Thu, Oct 11, 2018 at 11:55 AM Kristen Carlson Accardi
> wrote:
>>
>> This patch aims to make it harder to perform cache timing attacks on data
>> left behind by system calls. If we have an error returned from a syscall,
>> flush the L1
On Thu, Oct 11, 2018 at 11:55 AM Kristen Carlson Accardi
wrote:
>
> This patch aims to make it harder to perform cache timing attacks on data
> left behind by system calls. If we have an error returned from a syscall,
> flush the L1 cache.
>
> It's important to note that this patch is not addressi
On Thu, Oct 11, 2018 at 1:25 PM Alan Cox wrote:
>
> > Ugh.
> >
> > What exactly is this trying to protect against? And how many cycles
>
> Most attacks by speculation rely upon leaving footprints in the L1 cache.
> They also almost inevitably resolve non speculatively to errors. If you
> look thr
> Ugh.
>
> What exactly is this trying to protect against? And how many cycles
Most attacks by speculation rely upon leaving footprints in the L1 cache.
They also almost inevitably resolve non speculatively to errors. If you
look through all the 'yet another potential spectre case' patches peopl
On Thu, 2018-10-11 at 12:25 -0700, Andy Lutomirski wrote:
> On Thu, Oct 11, 2018 at 11:55 AM Kristen Carlson Accardi
> wrote:
> >
> > This patch aims to make it harder to perform cache timing attacks
> > on data
> > left behind by system calls. If we have an error returned from a
> > syscall,
> >
On Thu, Oct 11, 2018 at 11:55 AM Kristen Carlson Accardi
wrote:
>
> This patch aims to make it harder to perform cache timing attacks on data
> left behind by system calls. If we have an error returned from a syscall,
> flush the L1 cache.
>
> It's important to note that this patch is not addressi
This patch aims to make it harder to perform cache timing attacks on data
left behind by system calls. If we have an error returned from a syscall,
flush the L1 cache.
It's important to note that this patch is not addressing any specific
exploit, nor is it intended to be a complete defense against
22 matches
Mail list logo
