From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: [PATCH] Make sure get_user_desc() doesn't sign extend. Date: Wed, 21 Oct 2009 11:52:57 +0200 Message-ID: <4ADED9F9.3040006@redhat.com> References: <1256110829-4188-1-git-send-email-clalance@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mingo@redhat.com, x86@kernel.org, kvm@vger.kernel.org To: Chris Lalancette Return-path: Received: from mx1.redhat.com ([209.132.183.28]:14574 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752868AbZJUJxo (ORCPT ); Wed, 21 Oct 2009 05:53:44 -0400 In-Reply-To: <1256110829-4188-1-git-send-email-clalance@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 10/21/2009 09:40 AM, Chris Lalancette wrote: > The current implementation of get_user_desc() sign extends > the return value because of integer promotion rules. For > the most part, this doesn't matter, because the top bit of > base2 is usually 0. If, however, that bit is 1, then the > entire value will be 0xffff... which is probably not what > the caller intended. This patch casts the entire thing > to unsigned before returning, which generates almost the > same assembly as the current code but replaces the final > "cltq" (sign extend) with a "mov %eax %eax" (zero-extend). > This fixes booting certain guests under KVM. For the record, the reason why this wasn't noticed so far is that get_user_desc will be zero outside KVM except if used for FS and GS. KVM with the right guest will easily see a 0xC0000000 segment base, but you would need TLS data allocated above 2 GB to see the bug outside KVM. TLS data is in the same mmap-ed memory that hosts the thread stacks, so it will typically be below the 2 GB mark and have its most significant bit cleared. I suppose you could see the bug if you used pthread_attr_setstack, plus of course all the right circumstances---which are rare because all but the most obscure users anyway cast the result to u32. Paolo