> On 13 Oct 2022, at 20:12, Alejandro Colomar <alx.manpages@xxxxxxxxx> wrote: > > Hi Sam, Hi! > >>> [snip] >>> >> Maybe "capture" is not the best word. Maybe hooked / intercepted >> is better? > > Yeah intercepted might be better. > Done. >> F_S=3 lets cases where say, malloc size is based on a variable, >> still get detected because the compiler recognises such cases >> and adds scaffolding in to hook the functions. > > Adding something like this to the page might be helpful. I've put it in -- please let me know if it's helpful as-is or not. > >> (The malloc example at >> https://developers.redhat.com/articles/2022/09/17/gccs-new-fortification-level#1__a_new_builtin_provides_enhanced_buffer_size_detection >> is what I'm referring to). >> To be clear though: the semantics are similar to FORTIFY_SOURCE=2, >> it's just that FORITFY_SOURCE=3 uses an extra bit of information >> (__builtin_dynamic_object_size) to hook more cases. > > Maybe this is interesting (although maybe a bit too much into implementation details. I'll leave this part out for now, but keep the reference in the commit message. > > I'd like to know, from the point of view of a user who knows little about the different fortify levels (that actually matches me quite well :), what would be the constant differences (i.e., ones that the compiler will respect in the future (if there are any). What kind of guarantees there are or not. > What do you think about the latest state (I'll send v2 now)? It's hard because it's reliant on what the compiler can deduce, but the general idea is that it can go a step beyond and try to come up with an upper bound based on a variable, even if it can't get the exact size right, so it at least knows if you overshoot by a lot now. >> So whatever word works for FORTIFY_SOURCE < 3 works for 3 too. >> I'm definitely feeling like "capture" is not the best word but I'm >> struggling for the right one. > > If you're not inspired now, I'm fine adding whatever you want to add now; and we can revise it in the future. That's fine. > >> -- >> Additional question: there's actually some confusing >> constraints about when we can use F_S=3. >> It needs GCC 12 or Clang 9 as a compiler, >> and >= glibc-2.34. >> musl does not, at this time, support any >> built-in fortification. I don't know if we should >> mention that part. > > For sure. I was considering mailing musl maintainers to suggest that we could officially/consistently document musl, as it's become an important libc alternative in Linux distros. > I think this is a good idea. They might say the POSIX man pages should serve as documentation enough, but I think specifically documenting it will be useful -- not just for this fortification bit, but another example is actually time64 -- musl made a hard break in 1.2.x, hence no need for macros. I feel like that sort of information is useful for people so you have my full support in that and I'm happy to help. Best, sam
Attachment:
signature.asc
Description: Message signed with OpenPGP
