On 07/13/2018 10:56 AM, Yu-cheng Yu wrote: >>> GLIBC does the bitmap setup. It sets bits in there. >>> I thought you wanted a smaller bitmap? One way is forcing legacy libs >>> to low address, or not having the bitmap at all, i.e. turn IBT off. >> I'm concerned with two things: >> 1. the virtual address space consumption, especially the *default* case >> which will be apps using 4-level address space amounts, but having >> 5-level-sized tables. >> 2. the driving a truck-sized hole in the address space limits >> >> You can force legacy libs to low addresses, but you can't stop anyone >> from putting code into a high address *later*, at least with the code we >> have today. > So we will always reserve a big space for all CET tasks? Yes. You either hard-restrict the address space (which we can't do currently) or you reserve a big space. > Currently if an application does dlopen() a legacy lib, it will have only > partial IBT protection and no SHSTK. Do we want to consider simply turning > off IBT in that case? I don't know. I honestly don't understand the threat model enough to give you a good answer. Is there background on this in the docs? -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
