From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: speck@linutronix.de
Subject: [MODERATED] Re: terminal fault
Date: Wed, 18 Apr 2018 10:46:05 -0400 [thread overview]
Message-ID: <20180418144556.GA9939@localhost.localdomain> (raw)
In-Reply-To: <20180418083529.GT17484@dhcp22.suse.cz>
On Wed, Apr 18, 2018 at 10:35:29AM +0200, speck for Michal Hocko wrote:
> We have discussed the following patch as a mitigation for the native OS
> L1 Terminal fault issue.
>
> Intel was suggesting to set a bit outside of the uarch addressable range
> but flipping all the bits seems both easier and more future proof. So
> unless there is something else that would prevent such a fix I would
> vote to go with this patch.
>
> Thoughts?
> ---
> >From 7b03455455e1152988b2a295a917c0641f531fb0 Mon Sep 17 00:00:00 2001
> From: Michal Hocko <mhocko@suse.com>
> Date: Tue, 10 Apr 2018 14:10:42 +0200
> Subject: [PATCH] mm, swap, x86: make sure high bits of the swap offset are set
>
> Intel platforms have a bug where L1 cache contents can speculatively
> be used to load content of !present entries. This allows certain side
> channel attacks. We do have several different classes of !present
> pages. Unmapped memory clears the whole ptes so they are non-issue.
[Could you point to where this is done? I am just curious on this]
> mprotect, numa hints are referring to an existing pfns which cannot be
> tweaked by an attacker to a different privilege domains. So we are left
> with swap entries which encode the swap offset and that might conflict
> with an existing pfn. Obfuscate those entries by inverting bits in the
> swap offset which will set all the high bits and that _should_ stop the
> speculation as it should refer to the maximum addressable memory on all
> Intel platforms.
>
> Well this doesn't solve the problem on very large offsets (1<<30 on
> uarchs with 44b addressing) but this should be out of any practical
> attack space.
How does this help if your max memory is at the tip of the max physical support?
That would mean we will allow the top of the memory to leak in the L1
cache won't it?
>
> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
> Signed-off-by: Michal Hocko <mhocko@suse.com>
> ---
> arch/x86/include/asm/pgtable_64.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/include/asm/pgtable_64.h b/arch/x86/include/asm/pgtable_64.h
> index 1149d2112b2e..213c15b2e168 100644
> --- a/arch/x86/include/asm/pgtable_64.h
> +++ b/arch/x86/include/asm/pgtable_64.h
> @@ -299,10 +299,10 @@ static inline int pgd_large(pgd_t pgd) { return 0; }
>
> #define __swp_type(x) (((x).val >> (SWP_TYPE_FIRST_BIT)) \
> & ((1U << SWP_TYPE_BITS) - 1))
> -#define __swp_offset(x) ((x).val >> SWP_OFFSET_FIRST_BIT)
> +#define __swp_offset(x) (~(x).val >> SWP_OFFSET_FIRST_BIT)
> #define __swp_entry(type, offset) ((swp_entry_t) { \
> ((type) << (SWP_TYPE_FIRST_BIT)) \
> - | ((offset) << SWP_OFFSET_FIRST_BIT) })
> + | (~(offset) << SWP_OFFSET_FIRST_BIT) })
> #define __pte_to_swp_entry(pte) ((swp_entry_t) { pte_val((pte)) })
> #define __pmd_to_swp_entry(pmd) ((swp_entry_t) { pmd_val((pmd)) })
> #define __swp_entry_to_pte(x) ((pte_t) { .pte = (x).val })
> --
> 2.16.3
>
> --
> Michal Hocko
> SUSE Labs
next prev parent reply other threads:[~2018-04-18 14:46 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-18 8:35 [MODERATED] terminal fault Michal Hocko
2018-04-18 13:36 ` [MODERATED] " Jon Masters
2018-04-18 14:46 ` Konrad Rzeszutek Wilk [this message]
2018-04-19 7:28 ` Michal Hocko
2018-04-19 7:33 ` Jiri Kosina
2018-04-19 7:41 ` Michal Hocko
2018-04-19 7:52 ` Jiri Kosina
2018-04-19 17:02 ` Jon Masters
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180418144556.GA9939@localhost.localdomain \
--to=konrad.wilk@oracle.com \
--cc=speck@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.