* tboot: non-0 tboot_addr but it is not of type E820_RESERVED
@ 2015-11-24 1:57 Elliott, Robert (Persistent Memory)
2015-12-02 1:26 ` Elliott, Robert (Persistent Memory)
0 siblings, 1 reply; 3+ messages in thread
From: Elliott, Robert (Persistent Memory) @ 2015-11-24 1:57 UTC (permalink / raw)
To: joseph.cihula, richard.l.maliszewski, gang.wei, shane.wang
Cc: tglx, mingo, hpa, x86, tboot-devel, linux-kernel, Knippers,
Linda, Kani, Toshimitsu
I noticed this being reported on our UEFI-based machines booting
with grub2 (and not using trusted boot):
[ 0.000000] tboot: non-0 tboot_addr but it is not of type E820_RESERVED
The alleged address is:
0x6b7369642065766f
which is actually an ASCII string "ksid evo".
That comes from arch/c86/kernel/tboot.c checking if the address is
in the E820 table.
Is that supposed to be initialized to 0 by the EFI boot stub
in arch/x86/boot/compressed/eboot.c, and we're just lucky that it
doesn't appear to be a valid address?
void __init tboot_probe(void)
{
/* Look for valid page-aligned address for shared page. */
if (!boot_params.tboot_addr)
return;
/*
* also verify that it is mapped as we expect it before calling
* set_fixmap(), to reduce chance of garbage value causing crash
*/
if (!e820_any_mapped(boot_params.tboot_addr,
boot_params.tboot_addr, E820_RESERVED)) {
pr_warning("non-0 tboot_addr but it is not of type E820_RESERVED\n");
return;
}
That's part of this structure:
struct boot_params {
struct screen_info screen_info; /* 0x000 */
struct apm_bios_info apm_bios_info; /* 0x040 */
__u8 _pad2[4]; /* 0x054 */
__u64 tboot_addr; /* 0x058 */
struct ist_info ist_info; /* 0x060 */
...
---
Robert Elliott, HPE Persistent Memory
^ permalink raw reply [flat|nested] 3+ messages in thread* RE: tboot: non-0 tboot_addr but it is not of type E820_RESERVED
2015-11-24 1:57 tboot: non-0 tboot_addr but it is not of type E820_RESERVED Elliott, Robert (Persistent Memory)
@ 2015-12-02 1:26 ` Elliott, Robert (Persistent Memory)
2015-12-02 2:20 ` H. Peter Anvin
0 siblings, 1 reply; 3+ messages in thread
From: Elliott, Robert (Persistent Memory) @ 2015-12-02 1:26 UTC (permalink / raw)
To: joseph.cihula, richard.l.maliszewski, gang.wei, shane.wang
Cc: tglx, mingo, hpa, x86, tboot-devel, linux-kernel, Knippers,
Linda, Kani, Toshimitsu
> -----Original Message-----
> From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-
> owner@vger.kernel.org] On Behalf Of Elliott, Robert (Persistent Memory)
> Sent: Monday, November 23, 2015 7:58 PM
...
> Subject: tboot: non-0 tboot_addr but it is not of type E820_RESERVED
>
> I noticed this being reported on our UEFI-based machines booting
> with grub2 (and not using trusted boot):
> [ 0.000000] tboot: non-0 tboot_addr but it is not of type E820_RESERVED
>
> The alleged address is:
> 0x6b7369642065766f
> which is actually an ASCII string "ksid evo".
>
> That comes from arch/c86/kernel/tboot.c checking if the address is
> in the E820 table.
>
> Is that supposed to be initialized to 0 by the EFI boot stub
> in arch/x86/boot/compressed/eboot.c, and we're just lucky that it
> doesn't appear to be a valid address?
...
Per an hpa suggestion, I compared two versions of grub:
upstream grub (with "linux" in grub.cfg):
tboot_probe boot_params[0] = 0000008000000000 0000000000000070
tboot_probe boot_params[16] = 1000000400032000 0000009100003000
tboot_probe boot_params[32] = 3fa3001000100810 0808080008180000
tboot_probe boot_params[48] = 0000000000000000 0000000000000000
tboot probe boot_params[64] = 0000000000000000 0000000000000000
tboot_probe boot_params[80] = 0000000000000000 0000000000000000
tboot_probe boot_params[96] = 0000000000000000 0000000000000000
tboot_probe boot_params[112] = 0000000000000000 0000000000000000
tboot_probe boot_params[128] = 0000000000000000 0000000000000000
tboot_probe boot_params[144] = 0000000000000000 0000000000000000
tboot_probe boot_params[160] = 0000000000000000 0000000000000000
tboot_probe boot_params[176] = 0000000000000000 0000000000000000
tboot_probe boot_params[192] = 0000000000000000 0000000000000000
...
<no complaint about tboot_addr>
Fedora 22 grub (with "linuxefi" in grub.cfg):
tboot_probe boot_params[0] = 0000000000000000 0000000000000070
tboot_probe boot_params[16] = 0000000400032000 0000009100003000
tboot_probe boot_params[32] = 0000000000100810 0808080008180000
tboot_probe boot_params[48] = 0000010000000100 0000000000000000
tboot_probe boot_params[64] = 557365206120626f 6f74206c6f616465
tboot_probe boot_params[80] = 722e0d0a0a52656d 6f7665206469736b
tboot_probe boot_params[96] = 20616e6420707265 737320616e79206b
tboot_probe boot_params[112] = 657920746f207265 626f6f742e2e2e0d
tboot_probe boot_params[128] = 0a00504500006486 0400000000000000
tboot_probe boot_params[144] = 000001000000a000 06020b020214f017
tboot_probe boot_params[160] = 5c00000000001076 d200104600000002
tboot_probe boot_params[176] = 0000000000000000 0000200000002000
tboot_probe boot_params[192] = 0000000000000000 0000000000000000
...
[ 0.000000] tboot: non-0 tboot_addr 0x6b7369642065766f but it is not of type E820_RESERVED
In both cases, the kernel is compiled with CONFIG_EFI_STUB=y.
tboot_addr is at offset 88. Offset 64 is an ASCII string that says:
"Use a boot loader.
Remove disk and press any key to reboot..."
and is from arch/x86/boot/header.S, which is placing that string
at offset 64 (0x3c + 4) from .bstext (which precedes .bsdata) if
CONFIG_EFI_STUB is true.
#ifdef CONFIG_EFI_STUB
.org 0x3c
#
# Offset to the PE header.
#
.long pe_header
#endif /* CONFIG_EFI_STUB */
.section ".bsdata", "a"
bugger_off_msg:
.ascii "Use a boot loader.\r\n"
.ascii "\n"
.ascii "Remove disk and press any key to reboot...\r\n"
.byte 0
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: tboot: non-0 tboot_addr but it is not of type E820_RESERVED
2015-12-02 1:26 ` Elliott, Robert (Persistent Memory)
@ 2015-12-02 2:20 ` H. Peter Anvin
0 siblings, 0 replies; 3+ messages in thread
From: H. Peter Anvin @ 2015-12-02 2:20 UTC (permalink / raw)
To: Elliott, Robert (Persistent Memory),
joseph.cihula, richard.l.maliszewski, gang.wei, shane.wang
Cc: tglx, mingo, x86, tboot-devel, linux-kernel, Knippers, Linda,
Kani, Toshimitsu
On 12/01/15 17:26, Elliott, Robert (Persistent Memory) wrote:
>
> Per an hpa suggestion, I compared two versions of grub:
>
> upstream grub (with "linux" in grub.cfg):
> tboot_probe boot_params[0] = 0000008000000000 0000000000000070
> tboot_probe boot_params[16] = 1000000400032000 0000009100003000
> tboot_probe boot_params[32] = 3fa3001000100810 0808080008180000
> tboot_probe boot_params[48] = 0000000000000000 0000000000000000
> tboot probe boot_params[64] = 0000000000000000 0000000000000000
> tboot_probe boot_params[80] = 0000000000000000 0000000000000000
> tboot_probe boot_params[96] = 0000000000000000 0000000000000000
> tboot_probe boot_params[112] = 0000000000000000 0000000000000000
> tboot_probe boot_params[128] = 0000000000000000 0000000000000000
> tboot_probe boot_params[144] = 0000000000000000 0000000000000000
> tboot_probe boot_params[160] = 0000000000000000 0000000000000000
> tboot_probe boot_params[176] = 0000000000000000 0000000000000000
> tboot_probe boot_params[192] = 0000000000000000 0000000000000000
> ...
> <no complaint about tboot_addr>
>
> Fedora 22 grub (with "linuxefi" in grub.cfg):
> tboot_probe boot_params[0] = 0000000000000000 0000000000000070
> tboot_probe boot_params[16] = 0000000400032000 0000009100003000
> tboot_probe boot_params[32] = 0000000000100810 0808080008180000
> tboot_probe boot_params[48] = 0000010000000100 0000000000000000
> tboot_probe boot_params[64] = 557365206120626f 6f74206c6f616465
> tboot_probe boot_params[80] = 722e0d0a0a52656d 6f7665206469736b
> tboot_probe boot_params[96] = 20616e6420707265 737320616e79206b
> tboot_probe boot_params[112] = 657920746f207265 626f6f742e2e2e0d
> tboot_probe boot_params[128] = 0a00504500006486 0400000000000000
> tboot_probe boot_params[144] = 000001000000a000 06020b020214f017
> tboot_probe boot_params[160] = 5c00000000001076 d200104600000002
> tboot_probe boot_params[176] = 0000000000000000 0000200000002000
> tboot_probe boot_params[192] = 0000000000000000 0000000000000000
> ...
> [ 0.000000] tboot: non-0 tboot_addr 0x6b7369642065766f but it is not of type E820_RESERVED
>
> In both cases, the kernel is compiled with CONFIG_EFI_STUB=y.
>
> tboot_addr is at offset 88. Offset 64 is an ASCII string that says:
> "Use a boot loader.
>
> Remove disk and press any key to reboot..."
>
> and is from arch/x86/boot/header.S, which is placing that string
> at offset 64 (0x3c + 4) from .bstext (which precedes .bsdata) if
> CONFIG_EFI_STUB is true.
>
> #ifdef CONFIG_EFI_STUB
> .org 0x3c
> #
> # Offset to the PE header.
> #
> .long pe_header
> #endif /* CONFIG_EFI_STUB */
>
> .section ".bsdata", "a"
> bugger_off_msg:
> .ascii "Use a boot loader.\r\n"
> .ascii "\n"
> .ascii "Remove disk and press any key to reboot...\r\n"
> .byte 0
>
Most likely the "linuxefi" boot method uses the EFI handover protocol,
however. It looks like they don't start with a properly zeroed structure...
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2015-12-02 2:20 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-11-24 1:57 tboot: non-0 tboot_addr but it is not of type E820_RESERVED Elliott, Robert (Persistent Memory)
2015-12-02 1:26 ` Elliott, Robert (Persistent Memory)
2015-12-02 2:20 ` H. Peter Anvin
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome