Rowhammer Resistant Coding in Sudo

Re:Rowhammer Resistant Coding in Sudo by jareklupinski on Sunday January 28, 2024 @05:48PM (#39170653)

can't edit original post, but i just realized after lining up the monospace how

  #define AUTH_SUCCESS        0x52a2925  /* 0101001010100010100100100101    */
  #define AUTH_FAILURE        0xad5d6da  /* 1010110101011101011011011010    */
  #define AUTH_INTR           0x69d61fc8 /* 1101001110101100001111111001000 */
  #define AUTH_ERROR          0x1629e037 /* 0010110001010011110000000110111 */
  #define AUTH_NONINTERACTIVE 0x1fc8d3ac /* 11111110010001101001110101100   */

AUTH_FAILURE is still just !AUTH_SUCCESS (and almost a palindrome)

[ Parent | on HN ]

Re:Rowhammer Resistant Coding in Sudo by kelnos on Sunday January 28, 2024 @10:10PM (#39172291)

It sorta is, but isn't actually, sadly. I mean, if they were 28-bit values, they'd be binary complements, but they're actually 32-bit values, so they're really:

  #define AUTH_SUCCESS        0x052a2925  /* 00000101001010100010100100100101    */
  #define AUTH_FAILURE        0x0ad5d6da  /* 00001010110101011101011011011010    */

Doing a '!' operation in C on one of them won't yield the other value unless you also zero out the top 4 bits. Close enough, though... I still enjoy the symmetry as you did.

Anyway, I'm curious why three of the values they chose have all zeroes for the top 4 bits. I wonder if there's a security-related reason for that.

[ Parent | on HN ]

Re:Rowhammer Resistant Coding in Sudo by zaroth on Sunday January 28, 2024 @10:14PM (#39172321)

I think the theory is that means the most number of bits need to be flipped.

Because rowhammer is attacking the physical memory structure, it can’t function at the level that knows what AUTH_SUCCESS is.

This attack just targets raw bits, so we need to protect these crucial state variables from bit-flips.

[ Parent | on HN ]