linux-kernel - Re: [GIT PULL] Xen bugfixes

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20090910051648.GA1335@elte.hu>
Date:	Thu, 10 Sep 2009 07:16:48 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
Cc:	Ingo Molnar <mingo@...hat.com>,
	the arch/x86 maintainers <x86@...nel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Xen-devel <xen-devel@...ts.xensource.com>,
	Stable Kernel <stable@...nel.org>, Tejun Heo <tj@...nel.org>
Subject: Re: [GIT PULL] Xen bugfixes


* Jeremy Fitzhardinge <jeremy@...p.org> wrote:

> Hi,
> 
> Here's 3 patches which fix two Xen PV spinlock bugs, and makes 
> CONFIG_CC_STACKPROTECTOR work on both 32- and 64-bit.
> 
> The spinlock bugs are both rare races:
>  - lock can briefly hold the lock while interrupts are enabled, allowing an ISR to deadlock
>  - unlock doesn't enforce CPU memory ordering between the actual unlock write and the check
>    to see if there are any pending waiters, so it can end up deciding there's nobody to
>    kick on unlock, leaving another CPU hanging.  It needs a full mb() to guarantee the correct
>    ordering.
> 
> The stack-protector fix bites the bullet and does a full GDT setup 
> early so that we can load %gs for the stack-protector canary 
> segment on i386.  This also removes the assumption that the 
> initial percpu %fs segment has a zero base.
> 
> x86-64 still just needs the GS_BASE MSR written, but that now 
> happens using the same code as i386 rather than being special 
> cased.
> 
> Thanks,
> 	J
> 
> The following changes since commit e07cccf4046978df10f2e13fe2b99b2f9b3a65db:
>   Linus Torvalds (1):
>         Linux 2.6.31-rc9
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git bugfix
> 
> Jeremy Fitzhardinge (2):
>       xen: make -fstack-protector work under Xen
>       xen: only enable interrupts while actually blocking for spinlock
> 
> Yang Xiaowei (1):
>       xen: use stronger barrier after unlocking lock
> 
>  arch/x86/mm/Makefile     |    4 ++
>  arch/x86/xen/Makefile    |    2 +
>  arch/x86/xen/enlighten.c |  131 +++++++++++++++++++++++++++++++++++++++-------
>  arch/x86/xen/smp.c       |    1 +
>  arch/x86/xen/spinlock.c  |   28 ++++++----
>  drivers/xen/Makefile     |    3 +
>  6 files changed, 140 insertions(+), 29 deletions(-)

Pulled, thanks a lot Jeremy!

A few comments:

> +# Make sure __phys_addr has no stackprotector
> +nostackp := $(call cc-option, -fno-stack-protector)
> +CFLAGS_ioremap.o		:= $(nostackp)
> +

Sure we could move __phys_addr into its own file and thus avoid 
turning off stackprotector for the rest of ioremap.c?

> --- a/arch/x86/xen/Makefile
> +++ b/arch/x86/xen/Makefile
> @@ -8,6 +8,7 @@ endif
>  # Make sure early boot has no stackprotector
>  nostackp := $(call cc-option, -fno-stack-protector)
>  CFLAGS_enlighten.o		:= $(nostackp)
> +CFLAGS_mmu.o			:= $(nostackp)

A similar argument could be made here - what proportion of mmu.c is 
affected?

Also, once the commits have hit upstream feel free bounce them to 
stable@...nel.org - they dont have Cc: <stable@...nel.org> tags for 
automatic back-merging requests. The fixes narrowly missed v2.6.31.

	Ingo
--
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/