tboot: Avoid recursive fault in early boot panic with tboot

PATCH In review Jason Andryuk 3 participants 4 messages Jul 19, 2018 – Aug 28, 2018

Share & tools

Jason Andryuk

author

2018-07-19 10:39 UTC #0 lore raw

PATCH v2 1/1 tboot: Avoid recursive fault in early boot panic with tboot

If panic is called before init_idle_domain on a tboot-launched system, then Xen recursively faults in write_ptbase as seen below.

(XEN)    [<ffff82d080286690>] write_ptbase+0/0x10
(XEN)    [<ffff82d0802c4c3b>] tboot_shutdown+0x6b/0x260
(XEN)    [<ffff82d08029ddac>] machine_restart+0xac/0x2d0
(XEN)    [<ffff82d080286690>] write_ptbase+0/0x10
(XEN)    [<ffff82d0802446c1>] panic+0x111/0x120
(XEN)    [<ffff82d0802a51c1>] do_general_protection+0x171/0x1f0
(XEN)    [<ffff82d080287a82>] mm.c#virt_to_xen_l2e+0x12/0x1c0
(XEN)    [<ffff82d080354720>] x86_64/entry.S#handle_exception_saved+0x66/0xa4
(XEN)    [<ffff82d080286690>] write_ptbase+0/0x10
(XEN)    [<ffff82d0802c4c3b>] tboot_shutdown+0x6b/0x260
(XEN)    [<ffff82d08029ddac>] machine_restart+0xac/0x2d0
(XEN)    [<ffff82d0802446c1>] panic+0x111/0x120
(XEN)    [<ffff82d0803c11a0>] setup.c#bootstrap_map+0/0x11a
(XEN)    [<ffff82d0803b82a0>] flask_op.c#parse_flask_param+0/0xb0
(XEN)    [<ffff82d0803c11a0>] setup.c#bootstrap_map+0/0x11a
(XEN)    [<ffff82d0803b6f6c>] xsm_multiboot_init+0x7c/0xb0
(XEN)    [<ffff82d0803c34bb>] __start_xen+0x1d2b/0x2da0
(XEN)    [<ffff82d0802000f3>] __high_start+0x53/0x60

idle_vcpu[0] is still poisoned with INVALID_VCPU, so write_ptbase faults dereferencing the pointer. This fault calls panic and recurses through the same code path.

If tboot_shutdown is called while idle_vcpu[0] == INVALID_VCPU, then we are still operating with the initial page tables. Therefore changing page tables with write_ptbase is unnecessary.

An easy way to reproduce this is to use tboot to launch an XSM-enabled Xen without an XSM policy.

Signed-off-by Jason Andryuk <[email protected]>

---
v2: Correct comment and brace style

---
 xen/arch/x86/tboot.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

xen/arch/x86/tboot.c +6 -1

index fb4616ae83..d5a5292d7e 100644
@@ -391,7 +391,12 @@ void tboot_shutdown(uint32_t shutdown_type)
         tboot_gen_xenheap_integrity(g_tboot_shared->s3_key, &xenheap_mac);
     }
 
-    write_ptbase(idle_vcpu[0]);
+    /*
+     * During early boot, we can be called by panic before idle_vcpu[0] is
+     * setup, but in that case we don't need to change page tables.
+     */
+    if ( idle_vcpu[0] != INVALID_VCPU )
+        write_ptbase(idle_vcpu[0]);
 
     ((void(*)(void))(unsigned long)g_tboot_shared->shutdown_entry)();

Signature · 7 lines

2.17.1


_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel

Jan Beulich

Reviewed-by on v2 1/1

2018-07-19 10:55 UTC #1 lore raw

Quoted 27 lines

Quoted 1 line

Quoted 1 line · On 19.07.18 at 12:39, <[email protected]> wrote:

If panic is called before init_idle_domain on a tboot-launched system, then Xen recursively faults in write_ptbase as seen below.

(XEN)    [<ffff82d080286690>] write_ptbase+0/0x10
(XEN)    [<ffff82d0802c4c3b>] tboot_shutdown+0x6b/0x260
(XEN)    [<ffff82d08029ddac>] machine_restart+0xac/0x2d0
(XEN)    [<ffff82d080286690>] write_ptbase+0/0x10
(XEN)    [<ffff82d0802446c1>] panic+0x111/0x120
(XEN)    [<ffff82d0802a51c1>] do_general_protection+0x171/0x1f0
(XEN)    [<ffff82d080287a82>] mm.c#virt_to_xen_l2e+0x12/0x1c0
(XEN)    [<ffff82d080354720>] x86_64/entry.S#handle_exception_saved+0x66/0xa4
(XEN)    [<ffff82d080286690>] write_ptbase+0/0x10
(XEN)    [<ffff82d0802c4c3b>] tboot_shutdown+0x6b/0x260
(XEN)    [<ffff82d08029ddac>] machine_restart+0xac/0x2d0
(XEN)    [<ffff82d0802446c1>] panic+0x111/0x120
(XEN)    [<ffff82d0803c11a0>] setup.c#bootstrap_map+0/0x11a
(XEN)    [<ffff82d0803b82a0>] flask_op.c#parse_flask_param+0/0xb0
(XEN)    [<ffff82d0803c11a0>] setup.c#bootstrap_map+0/0x11a
(XEN)    [<ffff82d0803b6f6c>] xsm_multiboot_init+0x7c/0xb0
(XEN)    [<ffff82d0803c34bb>] __start_xen+0x1d2b/0x2da0
(XEN)    [<ffff82d0802000f3>] __high_start+0x53/0x60

idle_vcpu[0] is still poisoned with INVALID_VCPU, so write_ptbase faults dereferencing the pointer. This fault calls panic and recurses through the same code path.

Quoted 8 lines

If tboot_shutdown is called while idle_vcpu[0] == INVALID_VCPU, then we are still operating with the initial page tables. Therefore changing page tables with write_ptbase is unnecessary.
An easy way to reproduce this is to use tboot to launch an XSM-enabled Xen without an XSM policy.
Signed-off-by Jason Andryuk <[email protected]>

Reviewed-by Jan Beulich <[email protected]>

_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel

Jason Andryuk

author

2018-08-27 16:43 UTC #2 lore raw

In reply to Jason Andryuk

Quoted 27 lines · Jason Andryuk

If panic is called before init_idle_domain on a tboot-launched system, then Xen recursively faults in write_ptbase as seen below.

(XEN)    [<ffff82d080286690>] write_ptbase+0/0x10
(XEN)    [<ffff82d0802c4c3b>] tboot_shutdown+0x6b/0x260
(XEN)    [<ffff82d08029ddac>] machine_restart+0xac/0x2d0
(XEN)    [<ffff82d080286690>] write_ptbase+0/0x10
(XEN)    [<ffff82d0802446c1>] panic+0x111/0x120
(XEN)    [<ffff82d0802a51c1>] do_general_protection+0x171/0x1f0
(XEN)    [<ffff82d080287a82>] mm.c#virt_to_xen_l2e+0x12/0x1c0
(XEN)    [<ffff82d080354720>] x86_64/entry.S#handle_exception_saved+0x66/0xa4
(XEN)    [<ffff82d080286690>] write_ptbase+0/0x10
(XEN)    [<ffff82d0802c4c3b>] tboot_shutdown+0x6b/0x260
(XEN)    [<ffff82d08029ddac>] machine_restart+0xac/0x2d0
(XEN)    [<ffff82d0802446c1>] panic+0x111/0x120
(XEN)    [<ffff82d0803c11a0>] setup.c#bootstrap_map+0/0x11a
(XEN)    [<ffff82d0803b82a0>] flask_op.c#parse_flask_param+0/0xb0
(XEN)    [<ffff82d0803c11a0>] setup.c#bootstrap_map+0/0x11a
(XEN)    [<ffff82d0803b6f6c>] xsm_multiboot_init+0x7c/0xb0
(XEN)    [<ffff82d0803c34bb>] __start_xen+0x1d2b/0x2da0
(XEN)    [<ffff82d0802000f3>] __high_start+0x53/0x60

idle_vcpu[0] is still poisoned with INVALID_VCPU, so write_ptbase faults dereferencing the pointer. This fault calls panic and recurses through the same code path.

Quoted 8 lines

If tboot_shutdown is called while idle_vcpu[0] == INVALID_VCPU, then we are still operating with the initial page tables. Therefore changing page tables with write_ptbase is unnecessary.
An easy way to reproduce this is to use tboot to launch an XSM-enabled Xen without an XSM policy.
Signed-off-by Jason Andryuk <[email protected]>

Ping, Shane and Gang?

Quoted 25 lines

---
v2: Correct comment and brace style

---
 xen/arch/x86/tboot.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

xen/arch/x86/tboot.c +6 -2

index fb4616ae83..d5a5292d7e 100644
@@ -391,7 +391,12 @@ void tboot_shutdown(uint32_t shutdown_type)
         tboot_gen_xenheap_integrity(g_tboot_shared->s3_key, &xenheap_mac);
     }
 
-    write_ptbase(idle_vcpu[0]);
+    /*
+     * During early boot, we can be called by panic before idle_vcpu[0] is
+     * setup, but in that case we don't need to change page tables.
+     */
+    if ( idle_vcpu[0] != INVALID_VCPU )
+        write_ptbase(idle_vcpu[0]);
 
     ((void(*)(void))(unsigned long)g_tboot_shared->shutdown_entry)();
 
--

Quoted 2 lines

2.17.1

_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel

Wei, Gang

Acked-by

2018-08-28 02:41 UTC #3 lore raw

Quoted 35 lines · Jason Andryuk

Quoted 33 lines · Jason Andryuk
If panic is called before init_idle_domain on a tboot-launched system, then Xen recursively faults in write_ptbase as seen below.
(XEN)    [<ffff82d080286690>] write_ptbase+0/0x10
(XEN)    [<ffff82d0802c4c3b>] tboot_shutdown+0x6b/0x260
(XEN)    [<ffff82d08029ddac>] machine_restart+0xac/0x2d0
(XEN)    [<ffff82d080286690>] write_ptbase+0/0x10
(XEN)    [<ffff82d0802446c1>] panic+0x111/0x120
(XEN)    [<ffff82d0802a51c1>] do_general_protection+0x171/0x1f0
(XEN)    [<ffff82d080287a82>] mm.c#virt_to_xen_l2e+0x12/0x1c0
(XEN)    [<ffff82d080354720>] x86_64/entry.S#handle_exception_saved+0x66/0xa4
(XEN)    [<ffff82d080286690>] write_ptbase+0/0x10
(XEN)    [<ffff82d0802c4c3b>] tboot_shutdown+0x6b/0x260
(XEN)    [<ffff82d08029ddac>] machine_restart+0xac/0x2d0
(XEN)    [<ffff82d0802446c1>] panic+0x111/0x120
(XEN)    [<ffff82d0803c11a0>] setup.c#bootstrap_map+0/0x11a
(XEN)    [<ffff82d0803b82a0>] flask_op.c#parse_flask_param+0/0xb0
(XEN)    [<ffff82d0803c11a0>] setup.c#bootstrap_map+0/0x11a
(XEN)    [<ffff82d0803b6f6c>] xsm_multiboot_init+0x7c/0xb0
(XEN)    [<ffff82d0803c34bb>] __start_xen+0x1d2b/0x2da0
(XEN)    [<ffff82d0802000f3>] __high_start+0x53/0x60
idle_vcpu[0] is still poisoned with INVALID_VCPU, so write_ptbase faults dereferencing the pointer. This fault calls panic and recurses through the same code path.
If tboot_shutdown is called while idle_vcpu[0] == INVALID_VCPU, then we are still operating with the initial page tables. Therefore changing page tables with write_ptbase is unnecessary.

Quoted 6 lines

Quoted 4 lines
An easy way to reproduce this is to use tboot to launch an XSM-enabled Xen without an XSM policy.
Signed-off-by Jason Andryuk <[email protected]>
Ping, Shane and Gang?

Acked-by Gang Wei <[email protected]>

Quoted 23 lines

---
v2: Correct comment and brace style
---
xen/arch/x86/tboot.c | 7 ++++++-

1 file changed, 6 insertions(+), 1 deletion(-)

xen/arch/x86/tboot.c +6 -1

index fb4616ae83..d5a5292d7e 100644
@@ -391,7 +391,12 @@ void tboot_shutdown(uint32_t shutdown_type)
        tboot_gen_xenheap_integrity(g_tboot_shared->s3_key, &xenheap_mac);
    }
 
-    write_ptbase(idle_vcpu[0]);
+    /*
+     * During early boot, we can be called by panic before idle_vcpu[0] is
+     * setup, but in that case we don't need to change page tables.
+     */
+    if ( idle_vcpu[0] != INVALID_VCPU )
+        write_ptbase(idle_vcpu[0]);

Quoted 5 lines

Quoted 5 lines
xen/arch/x86/tboot.c +0 -1
    ((void(*)(void))(unsigned long)g_tboot_shared->shutdown_entry)();
 
--
2.17.1

_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel