How to detect in runtime is KASLR enabled or disabled?

To answer the question:

$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-4.14.27-041427-generic root=UUID=f3f8e7bc-b337-4194-88b8-3a513f6be55b ro quiet splash loglevel=0 vga=current udev.log-priority=3 fastboot kaslr acpiphp.disable=1 crashkernel=384M-2G:128M,2G-:256M vt.handoff=7

Check your kernel command line. (example on debian 8)

$ cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-`uname -r` root=/dev/mapper/`hostname`-root ro quiet

kASLR is available starting with Ubuntu 14.10 but it is not enabled by default. Specify the "kaslr" option on the kernel command line to use kASLR.

Note: Enabling kASLR will disable the ability to enter hibernation mode.

source: https://wiki.ubuntu.com/Security/Features

I wasn't satisfied with the prior answers as they really don't get to the meat of validating what KASLR is all about - especially embedded or custom kernels that don't implement the same kernel command-line interface (e.g. ARM64 requires a device-tree chosen node called kaslr-seed to be present when the kernel boots. This is usually implemented by the bootloader using a secure random number generator).

At runtime I know of two things you can check:

1. the /proc/kallsyms file to see the symbol addresses in virtual memory address space.
2. lsmod to see the kernel module addresses in virtual memory address space. Note: On some machines, lsmod may not show the addresses. In that case, try using cat /proc/modules as root. If not using root, the addresses may be all zeros (cleared for security reasons). ~~Thanks to user @crass for the comment!~~

Both 1 & 2 are similar checks, but depending on what's available to you on your system, you might need to use one or the other.

1. /proc/kallsyms

To do so, simply look at the first few lines of /proc/kallsyms:

root@device:~# head -n 3 /proc/kallsyms
ffffff8008080000 t _head
ffffff8008080000 T _text
ffffff8008080800 T do_undefinstr

Note that the address for, e.g., _head is ffff ff80 0808 0000.

Now reboot your machine and check again.

root@device:~# head -n 3 /proc/kallsyms
ffffff9fc8c80000 t _head
ffffff9fc8c80000 T _text
ffffff9fc8c80800 T do_undefinstr

Note that the address for, e.g., _head is now ffff ff9f c8c8 0000.
Compare the high-level bytes and find that ffffff80080 != 0xffffff9fc8c so the addresses are being changed across reboots => KASLR is enabled.

2. lsmod

Similar to /proc/kallsyms method above: check lsmod, reboot, check lsmod again, and compare the addresses.

root@device:~# lsmod
iptable_filter 16384 0 - Live 0xffffffa1c49b9000
ip_tables 28672 1 iptable_filter, Live 0xffffffa1c49ad000

Note that the address for, e.g., iptable_filter is ffff ffa1 c49b 9000.

Now reboot your machine and check again.

root@device:~# lsmod
iptable_filter 16384 0 - Live 0xffffff2100716000
ip_tables 28672 1 iptable_filter, Live 0xffffff210070a000

Note that the address for, e.g., iptable_filter is now ffff ff21 0071 6000.
Compare the high-level bytes and find that ffffff2100716 != 0xffffffa1c49b9 so the addresses are being changed across reboots => KASLR is enabled.

You can do these tests iteratively to determine the quality of the randomness. How different are the addresses across reboots? Are there obvious patterns? The security benefit of KASLR is proportional to the quality of randomness, or entropy.

References:
Debugging Linux Kernels with KASL
Linux Kernel Driver Database for RANDOMIZE_BASE