From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.zytor.com (terminus.zytor.com [198.137.202.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E788F3CFF72 for ; Sun, 16 Aug 2026 21:13:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.137.202.136 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786914797; cv=none; b=bmGclUd5MhtbTTo42E3gCpSSbeMb+GuenVMu/y6wdptzvjhChni6bZAZUh9tY2Q+XiP4kI3broSmR+M8MZXOwnSJxe5fG9zvOX7ie9y1SU5baQetr9e2l1zSH/f29P3g/iqKreX8ijMhuJjhHTV3STQewrGcd+I//YN3Vj0/v9s= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786914797; c=relaxed/simple; bh=GiwyjB2WcWnvSZxETkiOscEvE+VaGbd2rLeLOkNrawA=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=F0NsxjDYmkiV4QCreWhrOxbltrr4e7Bs/MYFp0SXQF0R+DIX9q13yvxNDqhusf9vd30+ru9H7VPeYQiNIeFLH+ZpePdn3TQ1y1AqFI6tiarmuGihiTV+/4YDAfE3LflOYSOZeyDVxF51KbM4fgMAPzQxKObkBlyR5kDC+1oTMxo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zytor.com; spf=pass smtp.mailfrom=zytor.com; dkim=pass (2048-bit key) header.d=zytor.com header.i=@zytor.com header.b=HMYhS3+Z; arc=none smtp.client-ip=198.137.202.136 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zytor.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=zytor.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=zytor.com header.i=@zytor.com header.b="HMYhS3+Z" Received: from [IPV6:2601:646:8081:8d71:1832:d005:9e73:5869] ([IPv6:2601:646:8081:8d71:1832:d005:9e73:5869]) (authenticated bits=0) by mail.zytor.com (8.18.1/8.17.1) with ESMTPSA id 67GLCknd3870282 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Sun, 16 Aug 2026 14:12:47 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 67GLCknd3870282 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com; s=2026072801; t=1786914768; bh=bw2NnfjeMVBa90/FOXXnU5Q5K4Y0en2FVxDWYc4kzNs=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=HMYhS3+ZddYn0fDn+0+YCxBWVXaJhmd51rLkMYiy3Fn5mlG0by0pUmkKeqAustHwu PXVQFIFFCGPCo05CiO2wPFD5fcTv1cNI/MoBw2eCoJCybXhZYkmrAb6XtRtNsRAa7O 7TJ9y5Q4iKaxPUaK4GczpHbuvF/1kQH5i228ryJZtkqYjd3nhkxkxw5sB3UKgyUmWv zFtT1xivK/o5ZUpnrOTz/WVhE6JjY8yI1gQzkhzyNFJm4olnLeju3M8j4o8PP8I2Zy JcVGYgFRdv2yFhDRfMDFzoGqmP2sakA5euKZoCj//RtQujsMB7LfarVJGPat096C9u n5bIXOFet6Odw== Message-ID: <84120379-65b4-4251-9e09-1672e6bc8d79@zytor.com> Date: Sun, 16 Aug 2026 14:12:41 -0700 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: X86: Question about GDT loading To: Alexandre , x86@kernel.org Cc: tglx@kernel.org, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, linux-kernel@vger.kernel.org References: Content-Language: en-US, sv-SE From: "H. Peter Anvin" In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 2026-08-16 13:45, Alexandre wrote: > I was tracing the execution of the file "arch/x86/boot/compressed/head_32.S" > with gdb when I noticed that the address used for the GDT in the GDTR > structure pointed to the GDTR itself. > > This is weird because it would make the GDTR an entry in the GDT. > > I see that the code (line 64) loads address of the "gdt" label (line 172), > which contains the GDTR data and the GDT entries, into eax and then stores > that address, as the GDT offset field (line 65). > Also, the GDT size field is calculated including the size of the GDTR data. (I > unsure if that's intended) > > Taking a look with gdb and with the kernel compiled for i386, we can see that > the address being used in the "lgdt" instruction  (line 66) is the same one > being used as the offset for the GDT. > > gdb: > 0x10001d        lgdtl  (%eax) > (gdb) i r eax > eax            0xca2000            13246464 > (gdb) x/64bx 0xca2000 > 0xca2000:       0x1f    0x00    0x00    0x20    0xca    0x00    0x00    0x00 > 0xca2008:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00 > 0xca2010:       0xff    0xff    0x00    0x00    0x00    0x9a    0xcf    0x00 > 0xca2018:       0xff    0xff    0x00    0x00    0x00    0x92    0xcf    0x00 > 0xca2020:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00 > 0xca2028:       0x00    0x00    0x00    0x00    0x05    0x00    0x00    0x00 > 0xca2030:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00 > 0xca2038:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00 > (gdb) > > After the size field ( 0x1f 0x00 ) the address of the GDT points to the GDTR > ( 0x00 0x20 0xca 0x00 ). > > Please let me know if that is intended or not. > It is intended. Slot 0 in the GDT is not used, so it is a pretty common convention to stuff the pointer to the GDT itself into that slot. For 32 bits that is perfectly safe. On 64 bits, it ends up taking up slot 1 as well; this is *not* safe for a kernel address as it would be interpreted as a user-space code descriptor for a single-byte code segment somewhere in the low 16 MB of memory, addressable as 0x13:0. This could be used to derive bits [55:32] of the kernel GDT base from user space. Therefore this must NOT be done in 64-bit mode. -hpa