davidlt has quit [Remote host closed the connection]
davidlt has joined #fedora-riscv
fuwei has joined #fedora-riscv
<sorear>
rwmjones: what does "enabling that" mean? if some random package doesn't work with it, who is responsible for dealing with that? does it also affect the default behavior of the installed gcc?
<sorear>
(vs. only spec files)
fuwei has quit [Ping timeout: 268 seconds]
cyberpear has joined #fedora-riscv
davidlt has quit [Ping timeout: 256 seconds]
<rwmjones>
sorear: well for RHEL packages that we ship, Red Hat is ultimately responsible
<rwmjones>
we have a scanning process that checks every binary has CFI enabled which prevents us (mostly) from shipping them
<rwmjones>
I think the changes to enable CFI went into redhat-rpm-config
<sorear>
would it be fair to say it becomes much less useful if there are _any_ packages it can't be enabled for?
<rwmjones>
for C/C++/Rust programs I don't think it's an issue, it's mainly been a problem in non-C ecosystems where we have to add support to the compiler (as was done with OCaml for example)
<rwmjones>
CFI is fairly non-intrusive, it just means adding endbr64 to functions and a bit more of a headache with ret/jmp
<sorear>
trying to work out exactly what level of intrusiveness is acceptable for RISC-V, one of the committers has proposed dropping the support for loading non-CFI DSOs in a process where the initial executable was CFI
<sorear>
(dlopen)
<rwmjones>
I think it should work however x86-64 works
<rwmjones>
(which I have no idea)
<sorear>
x86-64 is incompatible with POSIX.1-2004 and last I checked the dlopen issue is somewhat up in the air even there