On Thu, Jun 7, 2018 at 9:35 PM, Andy Lutomirski <luto@xxxxxxxxxx> wrote: > On Thu, Jun 7, 2018 at 9:22 PM H.J. Lu <hjl.tools@xxxxxxxxx> wrote: >> >> On Thu, Jun 7, 2018 at 3:02 PM, H.J. Lu <hjl.tools@xxxxxxxxx> wrote: >> > On Thu, Jun 7, 2018 at 2:01 PM, Andy Lutomirski <luto@xxxxxxxxxx> wrote: >> >> On Thu, Jun 7, 2018 at 1:33 PM Yu-cheng Yu <yu-cheng.yu@xxxxxxxxx> wrote: >> >>> >> >>> On Thu, 2018-06-07 at 11:48 -0700, Andy Lutomirski wrote: >> >>> > On Thu, Jun 7, 2018 at 7:41 AM Yu-cheng Yu <yu-cheng.yu@xxxxxxxxx> wrote: >> >>> > > >> >>> > > The following operations are provided. >> >>> > > >> >>> > > ARCH_CET_STATUS: >> >>> > > return the current CET status >> >>> > > >> >>> > > ARCH_CET_DISABLE: >> >>> > > disable CET features >> >>> > > >> >>> > > ARCH_CET_LOCK: >> >>> > > lock out CET features >> >>> > > >> >>> > > ARCH_CET_EXEC: >> >>> > > set CET features for exec() >> >>> > > >> >>> > > ARCH_CET_ALLOC_SHSTK: >> >>> > > allocate a new shadow stack >> >>> > > >> >>> > > ARCH_CET_PUSH_SHSTK: >> >>> > > put a return address on shadow stack >> >>> > > >> >> >> And why do we need ARCH_CET_EXEC? >> >> >> >> For background, I really really dislike adding new state that persists >> >> across exec(). It's nice to get as close to a clean slate as possible >> >> after exec() so that programs can run in a predictable environment. >> >> exec() is also a security boundary, and anything a task can do to >> >> affect itself after exec() needs to have its security implications >> >> considered very carefully. (As a trivial example, you should not be >> >> able to use cetcmd ... sudo [malicious options here] to cause sudo to >> >> run with CET off and then try to exploit it via the malicious options. >> >> >> >> If a shutoff is needed for testing, how about teaching ld.so to parse >> >> LD_CET=no or similar and protect it the same way as LD_PRELOAD is >> >> protected. Or just do LD_PRELOAD=/lib/libdoesntsupportcet.so. >> >> >> > >> > I will take a look. >> >> We can use LD_CET to turn off CET. Since most of legacy binaries >> are compatible with shadow stack, ARCH_CET_EXEC can be used >> to turn on shadow stack on legacy binaries: > > Is there any reason you can't use LD_CET=force to do it for > dynamically linked binaries? We need to enable shadow stack from the start. Otherwise function return will fail when returning from callee with shadow stack to caller without shadow stack. > I find it quite hard to believe that forcibly CET-ifying a legacy > statically linked binary is a good idea. We'd like to provide protection as much as we can. -- H.J.
