Draft for (complex) hash labeling scheme

[kito-cheng]

Dump some content from my offlist discussion with @ved-rivos :P

Introduce one more function in asm syntax: %lpad_label("<signature-string>").
e.g. lpad %lpad_label("v(i,i)"), lui t2, %lpad_label("v(i,i)") for void foo(int, int)

The signature string sytax:

SIGNATURE-STRING := RETURN-TYPE '(' ARGS ')'
                  | RETURN-TYPE '(' ')'
RETURN-TYPE := TYPE-NAME

ARGS := ARGS ',' ARG
      | ARG

ARG  := TYPE-NAME

TYPE-NAME is using the mangling name in itanium c++ abi[1] and RISC-V psABI[2].
[1] https://itanium-cxx-abi.github.io/cxx-abi/abi.html#mangling-builtin
[2] https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/master/riscv-elf.adoc#c-name-mangling

The value is the hash result of the signature string, we may start from md5.

void foo(int, int) = %lpad_label("v(i,i)") = low20(md5("v(i,i)")) = low20(3a7a68c073dcdbd6ee282a598c2dc44e) = 0xdc44e

Why md5: no strong reason for using md5, but one reason is it's available on binutils and llvm already.
Why using mangling name defined in itanium c++ abi: Prevent us to define complicate rule for mangling name.

More example:
void bar(): v()
void *memset(void *, int, size_t): Pv(Pv,i,m)

[yetingk]

I have two questions about using function signatures as landing label on function prologue.

1. Landing label for indirect branches within a function. A simple proposal is also to use the function signature as the landing pad. The benefit is it allows indirect branch to its function entry. But it also increase the risk of indirect calls which are not landed to a function entry.
2. We may need to have a landing label for the next pc of dual return functions like setjmp.

[kito-cheng]

Landing label for indirect branches within a function. A simple proposal is also to use the function signature as the landing pad. The benefit is it allows indirect branch to its function entry. But it also increase the risk of indirect calls which are not landed to a function entry.

A branch within a function is not expose to other module, so IMO that could be implementation defined.

We may need to have a landing label for the next pc of dual return functions like setjmp.

Generally those function are using ret to return function, so they don't need landing pad, however I found x86 has some special function attribute called indirect_return, we might take a look for that to see if we need to define a same one as well.

[samitolvanen]

Why md5: no strong reason for using md5, but one reason is it's available on binutils and llvm already.

I would prefer not to add more uses of MD5, even if in this application there aren't any actual security concerns. Since xxHash is also readily available, why not use that instead?

Why using mangling name defined in itanium c++ abi: Prevent us to define complicate rule for mangling name.

This name mangling scheme matches LLVM's existing forward-edge CFI implementations and I agree that it's a reasonable choice.

A simple proposal is also to use the function signature as the landing pad.

If you mean using the same label for the function entry and all the indirect branch targets in the function, I don't think that's acceptable. We should ensure that indirect calls are allowed only to function entry points.

A branch within a function is not expose to other module, so IMO that could be implementation defined.

I would suggest at least providing a recommendation for the indirect branch labeling scheme as well, so we won't end up with implementations that accidentally make CFI weaker.

[kito-cheng]

I would prefer not to add more uses of MD5, even if in this application there aren't any actual security concerns. Since xxHash is also readily available, why not use that instead?

Honestly I am not security guy, so that's my first time to heard xxHash, and I am open mind for other algorithm :)

A simple proposal is also to use the function signature as the landing pad.

If you mean using the same label for the function entry and all the indirect branch targets in the function, I don't think that's acceptable. We should ensure that indirect calls are allowed only to function entry points.

A branch within a function is not expose to other module, so IMO that could be implementation defined.

I would suggest at least providing a recommendation for the indirect branch labeling scheme as well, so we won't end up with implementations that accidentally make CFI weaker.

Yeah, sounds good idea.

[ved-rivos]

xxHash is not a cryptographic hash. xxHash is faster to compute. MD5 is also used by LLVM for CFI. For this purpose I would consider MD5 and xxHash to be equivalent.

For a branch within a function we could pick the convention of using the :<source_line_number>. That would restrict its scope.

[samitolvanen]

xxHash is not a cryptographic hash. xxHash is faster to compute. MD5 is also used by LLVM for CFI. For this purpose I would consider MD5 and xxHash to be equivalent.

The original CFI implementation in Clang uses MD5, but the newer ones (-fsanitize=kcfi and -fsanitize=function) have adopted xxHash:

https://github.com/llvm/llvm-project/blob/main/clang/lib/CodeGen/CodeGenFunction.cpp#L572
https://github.com/llvm/llvm-project/blob/main/clang/lib/CodeGen/CodeGenModule.cpp#L1995

For a branch within a function we could pick the convention of using the :<source_line_number>. That would restrict its scope.

Agreed, that's better. Ideally each branch target should have a unique label, so I would recommend including the file path in addition to the line number, for example.

[kito-cheng]

I suspect encoding line number may not work for all situation, one example is GNU C extension support "Labels as Values", but I do agree that should have different label than function, so I think we may add some note about that "NOTE: Targets of local indirect jumps that are not used for jump tables should have a landing pad. Additionally, the labeling value for these targets is recommended to be different from the function label value."

    void *ptr;

    if(...)
        ptr = &&foo;
    else
        ptr = &&bar;

    /* ... */
    goto *ptr;

foo:
    /* ... */

bar:
    /* ... */

[1] https://stackoverflow.com/questions/56316820/what-is-an-indirect-goto-statement
[2] https://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html

[samitolvanen]

I suspect encoding line number may not work for all situation, one example is GNU C extension support "Labels as Values"

Good point. Basically, all address-taken labels in a function must have the same landing pad label. We don't have to tie the label to the line number if that's confusing. It's enough that the label is unique within the program. E.g., HASH(path + counter).

NOTE: Targets of local indirect jumps that are not used for jump tables should have a landing pad.

Unless the compiler uses a software-guarded branch, the targets must have a landing pad. Do we want to include a recommendation for when it's safe to use a software-guarded branch?

Additionally, the labeling value for these targets is recommended to be different from the function label value.

This doesn't sound strong enough, because setting all indirect branch target labels to the same value would be enough in this case. How about recommending that each indirect branch target must have a landing pad label that's unique within the program, with the exception that all address-taken labels in the same function must have the same landing pad label?

[Yangff]

all address-taken labels in the same function must have the same landing pad label

what about the catch block which has a landing pad used by the runtime?

[samitolvanen]

what about the catch block which has a landing pad used by the runtime?

Please correct me if I'm wrong, but shouldn't C++ exceptions behave similarly to a function return, which means the exception landing pad won't need an lpad instruction?

[Yangff]

what about the catch block which has a landing pad used by the runtime?

Please correct me if I'm wrong, but shouldn't C++ exceptions behave similarly to a function return, which means the exception landing pad won't need an lpad instruction?

My impression is they use forward indirect jump to restore context instead of ret. This might be wrong though..

this vary by the implementation.. and for GCC and llvm it's just a ret.

[samitolvanen]

My impression is they use forward indirect jump to restore context instead of ret.

It depends on the architecture, but the RISC-V implementation in LLVM's libunwind seems to use ret at least:

https://github.com/llvm/llvm-project/blob/main/libunwind/src/UnwindRegistersRestore.S#L1159

Are you aware of other implementations that behave differently?

[Yangff]

My impression is they use forward indirect jump to restore context instead of ret.

It depends on the architecture, but the RISC-V implementation in LLVM's libunwind seems to use ret at least:

https://github.com/llvm/llvm-project/blob/main/libunwind/src/UnwindRegistersRestore.S#L1159

Are you aware of other implementations that behave differently?

You are right, it depends on the implementation. nongnu libunwind seems to use jr with non ra reg and GCC uses __builtin_eh_return which should be a ret.

With that said, it should be possible to assign a landingpad for it? Because that ret cannot be enforced by sspop since the address is not in stack anyway..

[samitolvanen]

Thanks for looking into this. It sounds like we should either require compatible implementations to use a return, or prepare a recommendation for exception handler landing pad labeling as well since there are implementations that use indirect jumps with a non-ra register.

Because that ret cannot be enforced by sspop since the address is not in stack anyway..

That's no different from setjmp etc. though. How much of a concern is this?