[PATCH] D122841: [analyzer] Consider all addrspaces in null dereference check

Wed Apr 6 02:29:11 PDT 2022

steakhal added a comment.

In D122841#3431617 <https://reviews.llvm.org/D122841#3431617>, @NoQ wrote:

> I looked up the history. I believe this refers to https://clang.llvm.org/docs/LanguageExtensions.html#memory-references-to-specified-segments:
>
>> Annotating a pointer with address space #256 causes it to be code generated relative to the X86 GS segment register, address space #257 causes it to be relative to the X86 FS segment, and address space #258 causes it to be relative to the X86 SS segment. Note that this is a very very low-level feature that should only be used if you know what you’re doing (for example in an OS kernel).
>
> So basically `((void *__attribute__((address_space(256))) *)0)` is a valid pointer that can be safely dereferenced.

Well, it seems like, on Windows, the `FS` register points to the `Win32 Thread Environment Block - TEB` (wiki <https://en.wikipedia.org/wiki/Win32_Thread_Information_Block>). And at offset `0x0`, resides the pointer to the `Current Structured Exception Handling (SEH) frame`, making it perfectly valid to load and dereference `FS:[0]`. Using `FS` and `GS` registers are frequently used for implementing anti-debug tricks <https://anti-debug.checkpoint.com/techniques/debug-flags.html#manual-checks-peb-beingdebugged-flag> in practice, but I think it's fairly safe to say that they are not our primary audience.

> I'm not aware of other situations of this kind. Probably this address space range can be hardcoded, and/or a run-time checker option can be provided to enable/disable this behavior.

That being said, I think it might deserve a //user-facing// analyzer config option.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D122841/new/

https://reviews.llvm.org/D122841