8 ms·

Yes it's possible, but it's not desirable. It wouldn't be backwards compatible, and not safe for shared libraries. It's better suited for a linter-type error/wa

by f_devd 3y ago

Yes it's possible, but it's not desirable. It wouldn't be backwards compatible, and not safe for shared libraries. It's better suited for a linter-type error/warning.

andrewaylett 3y ago
It's not plausible in C, for the reasons you mention, but it might be more possible in other languages -- Rust, for example, only guarantees specific representations when instructed and doesn't allow for shared libraries without a specified representation, so it wouldn't have either issue for most application code. Dynamically-typed languages similarly should be able to choose enum values at runtime in many cases.
- rcthompson 3y ago
  > Dynamically-typed languages similarly should be able to choose enum values at runtime in many cases. I wonder, is choosing random enum values at runtime more secure against Rowhammer than just having fixed values that were chosen randomly once and compiled in, since presumably the attacking code now has no way to know which bits it needs to flip? If so, it might even be desirable to implement this as a "secure enum" in a compiled language.
  - mcculley 3y ago
    From the commit: “The values used were chosen such that it takes a large number of bit flips to change from allowed to denied. Using random values doesn't really protect against this attack.” It would be neat to see an algorithm that generates suitable values.
    - f_devd 3y ago
      The basic algorithm for the 2-enum case from the commit seems to just be `enum { A = rand(), B = ~A}`. Although I'm not sure if it's optimal, the many case seems to be the same as the 2-case but repeated for every 2 items. I expect they double checked that the amount of bitflips is still pretty high. Maybe a better algorithm for the many case would be something like the popcnt parallel patterns: * 0b0101010101010101 * 0b0011001100110011 * 0b0000111100001111 * 0b0000000011111111 Since they would all have equal hamming distance between each of the entries.
      - mcculley 3y ago
        Yeah, I was specifically wondering about n>2. Your approach seems reasonable.
      - tomsmeding 3y ago
        The n=2 case also occurs in the commit: https://github.com/sudo-project/sudo/commit/7873f8334c8d31031f8cfa83bd97ac6029309e4f#diff-bc39bcb6f7119485e73eb37357a3e3ae1123fe09ac06b040f090b3218f186cb1R39 https://github.com/sudo-project/sudo/commit/7873f8334c8d3103... And indeed, the two values ate bitwise complements.

by f_devd 3y ago

Yes it's possible, but it's not desirable. It wouldn't be backwards compatible, and not safe for shared libraries. It's better suited for a linter-type error/warning.

andrewaylett 3y ago

It's not plausible in C, for the reasons you mention, but it might be more possible in other languages -- Rust, for example, only guarantees specific representations when instructed and doesn't allow for shared libraries without a specified representation, so it wouldn't have either issue for most application code. Dynamically-typed languages similarly should be able to choose enum values at runtime in many cases.

rcthompson 3y ago
> Dynamically-typed languages similarly should be able to choose enum values at runtime in many cases. I wonder, is choosing random enum values at runtime more secure against Rowhammer than just having fixed values that were chosen randomly once and compiled in, since presumably the attacking code now has no way to know which bits it needs to flip? If so, it might even be desirable to implement this as a "secure enum" in a compiled language.
- mcculley 3y ago
  From the commit: “The values used were chosen such that it takes a large number of bit flips to change from allowed to denied. Using random values doesn't really protect against this attack.” It would be neat to see an algorithm that generates suitable values.
  - f_devd 3y ago
    The basic algorithm for the 2-enum case from the commit seems to just be `enum { A = rand(), B = ~A}`. Although I'm not sure if it's optimal, the many case seems to be the same as the 2-case but repeated for every 2 items. I expect they double checked that the amount of bitflips is still pretty high. Maybe a better algorithm for the many case would be something like the popcnt parallel patterns: * 0b0101010101010101 * 0b0011001100110011 * 0b0000111100001111 * 0b0000000011111111 Since they would all have equal hamming distance between each of the entries.
    - mcculley 3y ago
      Yeah, I was specifically wondering about n>2. Your approach seems reasonable.
    - tomsmeding 3y ago
      The n=2 case also occurs in the commit: https://github.com/sudo-project/sudo/commit/7873f8334c8d31031f8cfa83bd97ac6029309e4f#diff-bc39bcb6f7119485e73eb37357a3e3ae1123fe09ac06b040f090b3218f186cb1R39 https://github.com/sudo-project/sudo/commit/7873f8334c8d3103... And indeed, the two values ate bitwise complements.