linux-kernel - Re: [GIT PULL] x86 fixes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20100116221211.GC5725@lenovo>
Date:	Sun, 17 Jan 2010 01:12:11 +0300
From:	Cyrill Gorcunov <gorcunov@...il.com>
To:	Ian Campbell <ijc@...lion.org.uk>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org,
	"H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [GIT PULL] x86 fixes

On Sat, Jan 16, 2010 at 09:16:56PM +0000, Ian Campbell wrote:
...
> > |
> > | > Yeah, I didn't found any explicit %ss reloading for this _particular_
> > | > case (as I marked in patch changelog). So the only suspicious is Xen
> > | > itself. So as only Christian get ability to test -- we will see the
> > | > results.
> > |
> > | The difference with Xen is that it must squash the RPL of SS (to 3 for
> > | 64 bit and 1 for 32 bit, 32 bit doesn't matter here though). Perhaps a
> > | NULL selector can only have RPL==0? (I'm away from my architecture docs
> > | so I can't check). In any case specifying a non-NULL SS selector allows
> > | the squashing to occur correctly.
> > |
> >
> > In turn reported said that only _this_ patch alone doesn't help him and
> > Ian replied we need both patches.
> >
> > Ian CC'ed if details needed.
>
> Thanks, I think you've covered or quoted everything.
>
> Although I think Linus' basic point is still valid -- why isn't a valid
> SS needed for 32 bit? The selectors have real meaning there even for
> native, don't they?
>

Well, the point was (I suppose) why we've started to set SS selector here
at all. It's due to Xen. Old code was doing so, and that happened Xen is
relating on it (as you actually said).

Also this is kernel thread which is supposed to execute in kernel space.
And kernel itself already set SS selector when it needs. So to eliminate
redunant operations we don't set SS here. And if there was not such
issue on a Xen side -- we would not set SS here as well.

Again, to be fair I just don't have rights to blame Xen here -- I rely on your
and Christian reports only.

> (I'm travelling all tomorrow and unlikely to be getting mail).
>
> Ian.
>

	-- Cyrill
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/