rcvalle wrote:
I haven't received a reply for my concerns I commented at
https://github.com/llvm/llvm-project/pull/117121#issuecomment-2502346476 and
https://github.com/llvm/llvm-project/pull/117121#issuecomment-2516251353, and
they still remain for the alternative proposal.
I'd recommend wor
rcvalle wrote:
I'm still trying to understand why a collision with a function of different
arity is riskier than a collision with a function of the same arity, as there
are so many factors that can account for it, such as:
* What registers that attacker has control of.
* How the registers that
rcvalle wrote:
This all too architecture specific and isn't the level that LLVM CFI and KCFI
originally work. The arity test should be at the language level. E.g.:
void foo(void) is arity zero
void bar(int) is arity 1
int baz(int) is arity 2
int qux(int, int) is arity 3
And so on. If we tried
rcvalle wrote:
Sorry, what I meant was we should be looking only at the number of return (with
void being zero, and everything else being one) and parameters from the
function declaration/definition and shouldn't be looking at the parameters'
type layout (i.e., size), and how and what register
rcvalle wrote:
> Flag guarding this feature seems like it would also be good for any existing
> C users - for example, if trying to build a kernel module intended to load
> against a kernel image built with an older `clang`, you need to select the
> same type ID projection that the kernel did.
rcvalle wrote:
LGTM. Thanks again for your time and for working on this, @samitolvanen! Much
appreciated.
https://github.com/llvm/llvm-project/pull/104826
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/l
rcvalle wrote:
Thank you for your time and for working on this, @samitolvanen! Much
appreciated.
How about changing the module flag name to "cfi-normalize-integers" to be more
consistent with the naming convention used, and as these could've also possibly
happened in regular CFI and with user
