Date: Tue, 11 Sep 2018 18:12:43 +0200 From: Jann Horn <jannh@...gle.com> To: kristen@...ux.intel.com Cc: Kernel Hardening <kernel-hardening@...ts.openwall.com> Subject: Re: [RFC PATCH] x86: entry: flush the cache if syscall error On Tue, Sep 11, 2018 at 5:58 PM Kristen C Accardi <kristen@...ux.intel.com> wrote: > On Mon, 2018-09-10 at 22:32 +0200, Jann Horn wrote: > > On Mon, Sep 10, 2018 at 9:14 PM Kristen Carlson Accardi > > <kristen@...ux.intel.com> 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. [...] > > > +config SYSCALL_FLUSH > > > + bool "Clear L1 Cache on syscall errors" > > > + default y > > > + help > > > + Select to allow the L1 cache to be cleared upon return of > > > + an error code from a syscall. This will reduce the > > > likelyhood of > > > + speculative execution style attacks on syscalls. > > > > s/L1/L1D/ ? > > I can change this - the documentation for this msr mentioned that on > some processors the icache might be impacted as well - think that's > worth mentioning? Ah, whoops, I didn't realize that it isn't as clear-cut as "just flush L1D". I should've looked for the documentation first... nevermind, I guess. I don't want to turn this into a documentation bikeshed.
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.