On 2023/12/14 03:35, Kees Cook wrote: > On Wed, Dec 13, 2023 at 05:01:07PM +0800, Wang wrote: >> On 2023/12/13 16:48, Dan Li wrote: >>> + Likun >>> >>> On Tue, 28 Mar 2023 at 06:18, Sami Tolvanen <samitolva...@google.com> wrote: >>>> On Mon, Mar 27, 2023 at 2:30 AM Peter Zijlstra <pet...@infradead.org> >>>> wrote: >>>>> On Sat, Mar 25, 2023 at 01:54:16AM -0700, Dan Li wrote: >>>>> >>>>>> In the compiler part[4], most of the content is the same as Sami's >>>>>> implementation[3], except for some minor differences, mainly including: >>>>>> >>>>>> 1. The function typeid is calculated differently and it is difficult >>>>>> to be consistent. >>>>> This means there is an effective ABI break between the compilers, which >>>>> is sad :-( Is there really nothing to be done about this? >>>> I agree, this would be unfortunate, and would also be a compatibility >>>> issue with rustc where there's ongoing work to support >>>> clang-compatible CFI type hashes: >>>> >>>> https://github.com/rust-lang/rust/pull/105452 >>>> >>>> Sami >> >> >> Hi Peter and Sami >> >> I am Dan Li's colleague, and I will take over and continue the work of CFI. > > Welcome; this is great news! :) Thanks for picking up the work. > >> >> Regarding the issue of gcc cfi type id being compatible with clang, we >> have analyzed and verified: >> >> 1. clang uses Mangling defined in Itanium C++ ABI to encode the function >> prototype, and uses the encoding result as input to generate cfi type id; >> 2. Currently, gcc only implements mangling for the C++ compiler, and the >> function prototype coding generated by these interfaces is compatible >> with clang, but gcc's c compiler does not support mangling.; >> >> Adding mangling to gcc's c compiler is a huge and difficult task，because >> we have to refactor the mangling of C++, splitting it into basic >> mangling and language specific mangling, and adding support for the c >> language which requires a deep understanding of the compiler and >> language processing parts. >> >> And for the kernel cfi, I suggest separating type compatibility from CFI >> basic functions. Type compatibility is independent from CFI basic >> funcitons and should be dealt with under another topic. Should we focus >> on the main issus of cfi, and let it work first on linux kernel, and >> left the compatible issue to be solved later? > > If you mean keeping the hashes identical between Clang/LLVM and GCC, > I think this is going to be a requirement due to adding Rust to the > build environment (which uses the LLVM mangling and hashing). > > FWIW, I think the subset of type mangling needed isn't the entirely C++ > language spec, so it shouldn't be hard to add this to GCC. > > -Kees >
Thanks Kees, I will first try to implement a simple interface based on mangle to generate cfi type id. Likun Wang 声明：这封邮件只允许文件接收者阅读，有很高的机密性要求。禁止其他人使用、打开、复制或转发里面的任何内容。如果本邮件错误地发给了你，请联系邮件发出者并删除这个文件。机密及法律的特权并不因为误发邮件而放弃或丧失。任何提出的观点或意见只属于作者的个人见解，并不一定代表本公司。
