Re: [edk2-devel] Casting i128 into f64 in UEFI Rust pagefaults

["Pedro Falcato" <pedro.falcato@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 9625 bytes --]

Fyi, please don't file bugs upstream just now. You're not sure if they're
LLVM problems (and they're likely not, else they would affect everyone
else, not just UEFI code). Try to get a simpler, reliable repro (and do
share with us!) before saying it's an LLVM bug.
In my experience, most "what the hell" "compiler bugs" ended up being
things I accidentally set up wrong, or didn't set up at all, and broke
things in a subtle way.

On Tue, Jul 26, 2022 at 6:43 AM Ayush Singh <ayushdevel1325@gmail.com>
wrote:

> Hi Andrew. Thanks for all your work. The more I look at this, the more it
> feels like it might be a problem on the LLVM side instead of Rust. I also
> found some more tests (all related to numbers btw) which can cause
> different types of exceptions, so I think I will try filing bugs upstream.
>
> Yours Sincerely,
>
> Ayush Singh
>
>
> On 7/26/22 00:24, Andrew Fish wrote:
>
> I guess I could at least dump to the end (req)…. Going backwards is a bit
> painful in x86.
>
> (lldb) dis -s 0x0000000140001B60 -b -c 30
>
> hello_world_std.efi[0x140001b60]: 48 8b 09                       movq
> (%rcx), %rcx
>
> hello_world_std.efi[0x140001b63]: 48 01 c1                       addq
> %rax, %rcx
>
> hello_world_std.efi[0x140001b66]: 4c 89 c2                       movq
> %r8, %rdx
>
> hello_world_std.efi[0x140001b69]: 48 11 c2                       adcq
> %rax, %rdx
>
> hello_world_std.efi[0x140001b6c]: 48 31 c1                       xorq
> %rax, %rcx
>
> hello_world_std.efi[0x140001b6f]: 48 31 c2                       xorq
> %rax, %rdx
>
> hello_world_std.efi[0x140001b72]: 48 be 00 00 00 00 00 00 00 80  movabsq
> $-0x8000000000000000, %rsi ; imm = 0x8000000000000000
>
> hello_world_std.efi[0x140001b7c]: 4c 21 c6                       andq
> %r8, %rsi
>
> hello_world_std.efi[0x140001b7f]: e8 5c 55 00 00                 callq
> 0x1400070e0
>
> hello_world_std.efi[0x140001b84]: 48 09 f0                       orq
> %rsi, %rax
>
> hello_world_std.efi[0x140001b87]: 48 83 c4 20                    addq
> $0x20, %rsp
>
> hello_world_std.efi[0x140001b8b]: 5e                             popq
> %rsi
>
> hello_world_std.efi[0x140001b8c]: c3                             retq
>
> hello_world_std.efi[0x140001b8d]: cc                             int3
>
> hello_world_std.efi[0x140001b8e]: cc                             int3
>
> hello_world_std.efi[0x140001b8f]: cc                             int3
>
> hello_world_std.efi[0x140001b90]: e9 db 55 00 00                 jmp
> 0x140007170
>
> hello_world_std.efi[0x140001b95]: cc                             int3
> …
>
> Then we can guess based on how functions get aligned to find the start….
>
> hello_world_std.efi[0x140001b50]: 56
> pushq  %rsi
>
> hello_world_std.efi[0x140001b51]: 48 83 ec 20
> subq   $0x20, %rsp
>
> hello_world_std.efi[0x140001b55]: 4c 8b 41 08
> movq   0x8(%rcx), %r8
>
> hello_world_std.efi[0x140001b59]: 4c 89 c0
> movq   %r8, %rax
>
> hello_world_std.efi[0x140001b5c]: 48 c1 f8 3f
> sarq   $0x3f, %rax
>
> hello_world_std.efi[0x140001b60]: 48 8b 09
> movq   (%rcx), %rcx
>
> hello_world_std.efi[0x140001b63]: 48 01 c1
> addq   %rax, %rcx
>
> hello_world_std.efi[0x140001b66]: 4c 89 c2
> movq   %r8, %rdx
>
> hello_world_std.efi[0x140001b69]: 48 11 c2
> adcq   %rax, %rdx
>
> hello_world_std.efi[0x140001b6c]: 48 31 c1
> xorq   %rax, %rcx
>
> hello_world_std.efi[0x140001b6f]: 48 31 c2
> xorq   %rax, %rdx
>
> hello_world_std.efi[0x140001b72]: 48 be 00 00 00 00 00 00 00 80
> movabsq $-0x8000000000000000, %rsi ; imm = 0x8000000000000000
>
> hello_world_std.efi[0x140001b7c]: 4c 21 c6
> andq   %r8, %rsi
>
> hello_world_std.efi[0x140001b7f]: e8 5c 55 00 00
> callq  0x1400070e0
>
> hello_world_std.efi[0x140001b84]: 48 09 f0
> orq    %rsi, %rax
>
> hello_world_std.efi[0x140001b87]: 48 83 c4 20
> addq   $0x20, %rsp
>
> hello_world_std.efi[0x140001b8b]: 5e
> popq   %rsi
>
> hello_world_std.efi[0x140001b8c]: c3
> retq
>
> So the faulting function is getting passed a bad pointer as its 1st arg.
>
> Thanks,
>
> Andrew Fish
>
> On Jul 25, 2022, at 11:45 AM, Andrew Fish <afish@apple.com>
> <afish@apple.com> wrote:
>
> Ops… Looks like your PE/COFF is linked at 0x0000000140000000,
> so 0x140001b60 is the interesting bit.
>
> (lldb) dis -s 0x0000000140001B60 -b
> hello_world_std.efi[0x140001b60]: 48 8b 09                       movq
> (%rcx), %rcx
> hello_world_std.efi[0x140001b63]: 48 01 c1                       addq
> %rax, %rcx
> hello_world_std.efi[0x140001b66]: 4c 89 c2                       movq
> %r8, %rdx
> hello_world_std.efi[0x140001b69]: 48 11 c2                       adcq
> %rax, %rdx
> hello_world_std.efi[0x140001b6c]: 48 31 c1                       xorq
> %rax, %rcx
> hello_world_std.efi[0x140001b6f]: 48 31 c2                       xorq
> %rax, %rdx
> hello_world_std.efi[0x140001b72]: 48 be 00 00 00 00 00 00 00 80  movabsq
> $-0x8000000000000000, %rsi ; imm = 0x8000000000000000
> hello_world_std.efi[0x140001b7c]: 4c 21 c6                       andq
> %r8, %rsi
>
>  RCX - FFFFFFFFFFFFFFFF
>
> So yea that looks like the fault.
>
> I don’t see that pattern in your .s file….
>
> Can you figure out what function is @ 0x140001b60 in the PE/COFF image.
> Do you have a map file from the linker?
>
> Thanks,
>
> Andrew Fish
>
> PS Again sorry I don’t have anything installed to crack PDB files.
>
> Thanks,
>
> Andrew Fish
>
> On Jul 25, 2022, at 10:51 AM, Andrew Fish via groups.io
> <afish=apple.com@groups.io> <afish=apple.com@groups.io> wrote:
>
> Ayush,
>
> CR2 is the fault address so 0xFFFFFFFFFFFFFFFF. Given for EFI Virt ==
> Physical the fault address looks like a bad pointer.
>
> Sorry I’ve not used VC++ in a long time so I don’t know how to debug with
> VC++, but If I was using clang/lldb I’d look at the source and assembly for
> the fault address.
>
> The image base is: 0x000000000603C000
> The fault PC/RIP is: 000000000603DB60
>
> So the faulting code is at 0x1B60 in the image. Given the images are
> linked at zero you should be able to load the build product into the
> debugger and look at what code is at offset 0x1B60. The same should work
> for any tools that dump the binary.
>
> Thanks,
>
> Andrew Fish
>
> On Jul 25, 2022, at 10:33 AM, Ayush Singh <ayushdevel1325@gmail.com>
> <ayushdevel1325@gmail.com> wrote:
>
> Hello everyone.While running Rust tests in UEFI environment, I have come
> across a numeric test that causes a pagefault. A simple reproducible
> example for this is given below:
>
> ```rust
>
> fn main() {
>     use std::hint::black_box as b;
>
>     let z: i128 = b(1);
>     assert!((-z as f64) < 0.0);
> }
>
> ```
>
>
> The exception output is as follows:
>
> ```
>
> !!!! X64 Exception Type - 0E(#PF - Page-Fault)  CPU Apic ID - 00000000 !!!!
> ExceptionData - 0000000000000000  I:0 R:0 U:0 W:0 P:0 PK:0 SS:0 SGX:0
> RIP  - 000000000603DB60, CS  - 0000000000000038, RFLAGS - 0000000000000246
> RAX  - 0000000000000000, RCX - FFFFFFFFFFFFFFFF, RDX - FFFFFFFFFFFFFFFF
> RBX  - 0000000000000000, RSP - 0000000007EDF1D0, RBP - 0000000007EDF4C0
> RSI  - 0000000007EDF360, RDI - 0000000007EDF3C0
> R8   - 0000000000000000, R9  - 0000000000000038, R10 - 0000000000000000
> R11  - 0000000000000000, R12 - 00000000060C6018, R13 - 0000000007EDF520
> R14  - 0000000007EDF6A8, R15 - 0000000005FA9490
> DS   - 0000000000000030, ES  - 0000000000000030, FS  - 0000000000000030
> GS   - 0000000000000030, SS  - 0000000000000030
> CR0  - 0000000080010033, CR2 - FFFFFFFFFFFFFFFF, CR3 - 0000000007C01000
> CR4  - 0000000000000668, CR8 - 0000000000000000
> DR0  - 0000000000000000, DR1 - 0000000000000000, DR2 - 0000000000000000
> DR3  - 0000000000000000, DR6 - 00000000FFFF0FF0, DR7 - 0000000000000400
> GDTR - 00000000079DE000 0000000000000047, LDTR - 0000000000000000
> IDTR - 0000000007418018 0000000000000FFF,   TR - 0000000000000000
> FXSAVE_STATE - 0000000007EDEE30
> !!!! Find image based on IP(0x603DB60)
> /var/home/ayush/Documents/Programming/Rust/uefi/hello_world_std/target/x86_64-unknown-uefi/debug/deps/hello_world_std-338028f9369e2d42.pdb
> (ImageBase=000000000603C000, EntryPoint=000000000603D8C0) !!!!
>
> ```
>
>
> From my testing, the exception only occurs when a few conditions are met.
>
> 1. The binary is compiled in Debug mode. No error in Release mode.
>
> 2. `i128` is in a black_box [1]. Does not occur if `black_box` is not
> present.
>
> 3. It has to be `i128`. `i64` or something else work fine.
>
> 4. The cast has to be done on `-z`. Doing the same with `+z` is fine.
>
>
> I have also been discussing this in the Rust zulipchat [2], so feel free
> to chime in there.
>
>
> Additionally, here are links for more information about this program:
>
> 1. Assembly:
> https://rust-lang.zulipchat.com/user_uploads/4715/od51Y9Dkfjahcg9HHcOud8Fm/hello_world_std-338028f9369e2d42.s
>
> 2. EFI Binary:
> https://rust-lang.zulipchat.com/user_uploads/4715/CknqtXLR8SaJZmyOnXctQkpL/hello_world_std.efi
>
> 3. PDB file:
> https://rust-lang.zulipchat.com/user_uploads/4715/zV4i6DsjgQXotp_gS1naEsU0/hello_world_std-338028f9369e2d42.pdb
>
>
> Yours Sincerely,
>
> Ayush Singh
>
>
> [1]: https://doc.rust-lang.org/std/hint/fn.black_box.html
>
> [2]:
> https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/Casting.20i128.20to.20f64.20in.20black_box.20causes.20exception.20in.20UEFI
>
>
>
>
>
>
> 
>
>

-- 
Pedro Falcato

[-- Attachment #2: Type: text/html, Size: 66207 bytes --]