Announcement

Collapse
No announcement yet.

Google Wants LLVM To Mainline x32 ABI Support

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • phoronix
    started a topic Google Wants LLVM To Mainline x32 ABI Support

    Google Wants LLVM To Mainline x32 ABI Support

    Phoronix: Google Wants LLVM To Mainline x32 ABI Support

    The Google Native Client (NaCl) team is looking to upstream some of their LLVM changes such as support for Software Fault Isolation (SFI). As part of pushing forward the changes for Native Client in LLVM, they're also looking to see mainlined the x32 ABI support. X32 is the Application Binary Interface that looks to take advantage of common x86_64 CPU features like increased CPU registers and more instruction set extensions while using 32-bit pointers...

    http://www.phoronix.com/vr.php?view=MTI3NTk

  • JS987
    replied
    Originally posted by LightBit View Post
    This slides says 2m11s is needed on 64-bit
    Function get_random_int is different in latest kernels. Slides claim that it worked only for local attacker.

    Leave a comment:


  • LightBit
    replied
    Originally posted by JS987 View Post
    It is maybe also possible to detect it on 32-bit, but on 64-bit attack would last much longer, which means much higher probability of detection.
    This slides says 2m11s is needed on 64-bit

    Leave a comment:


  • JS987
    replied
    Originally posted by LightBit View Post
    Why it can't be detected on 32-bit?
    It is maybe also possible to detect it on 32-bit, but on 64-bit attack would last much longer, which means much higher probability of detection.

    Leave a comment:


  • LightBit
    replied
    Originally posted by JS987 View Post
    Brute force attack isn't always possible and can be detected.
    Why it can't be detected on 32-bit?

    Leave a comment:


  • JS987
    replied
    Originally posted by LightBit View Post
    Shall we use 128-bit pointers just to prevent brute force attack?
    40-bit (64-bit) can be brute forced quite fast.
    Brute force attack isn't always possible and can be detected.

    Leave a comment:


  • LightBit
    replied
    Originally posted by JS987 View Post
    I have 2^45 virtual memory according to /proc/meminfo
    If I understand correctly x32 is more for low memory devices.


    Originally posted by JS987 View Post
    According to http://www.stanford.edu/~blp/papers/asrandom.pdf 64-bit is more secure because of more bits of randomization.
    Shall we use 128-bit pointers just to prevent brute force attack?
    40-bit (64-bit) can be brute forced quite fast.

    Leave a comment:


  • JS987
    replied
    Originally posted by LightBit View Post
    1. ASLR is just makes attacks harder.
    2. Attacker can reduce searching to virtual memory size. (so ASLR is more efficient with 64-bit pointers, only if you have more than 2^32 virtual memory)
    I have 2^45 virtual memory according to /proc/meminfo
    According to http://www.stanford.edu/~blp/papers/asrandom.pdf 64-bit is more secure because of more bits of randomization.

    Leave a comment:


  • LightBit
    replied
    Originally posted by JS987 View Post
    32-bit pointers are insecure because of inefficient Address space layout randomization (ASLR).
    1. ASLR is just makes attacks harder.
    2. Attacker can reduce searching to virtual memory size. (so ASLR is more efficient with 64-bit pointers, only if you have more than 2^32 virtual memory)
    Last edited by LightBit; 01-24-2013, 09:11 AM.

    Leave a comment:


  • JS987
    replied
    32-bit pointers are insecure because of inefficient Address space layout randomization (ASLR).

    Leave a comment:

Working...
X