From: Borislav Petkov <bp@alien8.de>
To: Andy Lutomirski <luto@amacapital.net>
Cc: LKML <linux-kernel@vger.kernel.org>,
Andy Lutomirski <luto@kernel.org>,
"H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [RFC PATCH] x86/cpu: Fix MSR value truncation issue
Date: Fri, 30 Oct 2015 20:23:29 +0100 [thread overview]
Message-ID: <20151030192329.GJ20952@pd.tnic> (raw)
In-Reply-To: <CALCETrXpjxHFszxDYdT=iZo8O-x7eNy_FBePSkqTjVzZfVT-fg@mail.gmail.com>
On Fri, Oct 30, 2015 at 11:59:39AM -0700, Andy Lutomirski wrote:
> Is this with or without:
>
> commit 47edb65178cb7056c2eea0b6c41a7d8c84547192
> Author: Andy Lutomirski <luto@kernel.org>
> Date: Thu Jul 23 12:14:40 2015 -0700
>
> x86/asm/msr: Make wrmsrl() a function
with.
I'm playing ontop of 4.3-rc7.
> If that patch is applied, then I think that gcc is just being dumb and
Huh, why?
gcc is actually being smart by completely avoiding the shift to the
upper bits and puts those directly into %edx and sparse simply says that
we're truncating some bits.
I actually think that sparse is correct in saying that some bits are
going to be zeroed out even though we want that here.
> that we should consider tweaking wrmsrl to avoid generating the
> warning. Maybe change (u32)val to (u32)(val & 0xffffffffull)?
That works.
> I don't see why we should uglify the caller when the problem is some
> combination of gcc and the wrmsrl implementation.
Why uglify?
We're basically making explicit that we write the high 32-bits with the
SYSCALL and SYSRET CS and SS and we set the low 32-bit explicitly to 0:
wrmsr(MSR_STAR, 0, (__USER32_CS << 16) | __KERNEL_CS);
versus setting the low 32-bits to zero *implicitly*:
wrmsrl(MSR_STAR, ((u64)__USER32_CS)<<48 | ((u64)__KERNEL_CS)<<32);
due to that shifting to the left filling up the 32-bit with zeroes.
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
next prev parent reply other threads:[~2015-10-30 19:23 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-30 17:28 [RFC PATCH] x86/cpu: Fix MSR value truncation issue Borislav Petkov
2015-10-30 18:59 ` Andy Lutomirski
2015-10-30 19:23 ` Borislav Petkov [this message]
2015-10-30 19:26 ` Andy Lutomirski
2015-10-30 19:32 ` Borislav Petkov
2015-10-30 19:34 ` Andy Lutomirski
2015-10-31 11:46 ` [PATCH] x86/MSR: Chop off lower 32-bit value Borislav Petkov
2015-11-11 12:31 ` [RFC PATCH] x86/cpu: Fix MSR value truncation issue Borislav Petkov
2015-11-11 15:50 ` Andy Lutomirski
2015-11-11 16:05 ` Borislav Petkov
2015-11-11 18:07 ` Brian Gerst
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=20151030192329.GJ20952@pd.tnic \
--to=bp@alien8.de \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=luto@kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
/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.