Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 11 Sep 2018 10:41:48 +0200
From: Greg KH <>
To: Kristen Carlson Accardi <>
Subject: Re: [RFC PATCH] x86: entry: flush the cache if syscall error

On Mon, Sep 10, 2018 at 12:10:02PM -0700, 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.
> Signed-off-by: Kristen Carlson Accardi <>
> ---
>  arch/x86/Kconfig        |  8 ++++++++
>  arch/x86/entry/common.c | 20 ++++++++++++++++++++
>  2 files changed, 28 insertions(+)
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index c5ff296bc5d1..8a67642ff9fe 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -445,6 +445,14 @@ config RETPOLINE
>  	  code are eliminated. Since this includes the syscall entry path,
>  	  it is not entirely pointless.
> +	bool "Clear L1 Cache on syscall errors"
> +	default y

"y" normally is only for "your machine will not boot without this
option", and I don't think that's the case here :)

> +	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.

Shouldn't this help text refer to the fact that this needs CPU support
for this type of functionality?

I like the idea, as a "gadget" normally only is used when an
out-of-bands check happens, which implies someone could be trying to do
something "bad", nice job.


greg k-h

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.