On Fri, Mar 12, 2021 at 06:55:57PM +0200, Jarkko Sakkinen wrote: > On Wed, Mar 10, 2021 at 03:20:20PM -0800, Dave Hansen wrote: > > On 3/10/21 2:55 PM, Yu, Yu-cheng wrote: > > > On 3/10/2021 2:39 PM, Jarkko Sakkinen wrote: > > >> On Wed, Mar 10, 2021 at 02:05:19PM -0800, Yu-cheng Yu wrote: > > >>> When CET is enabled, __vdso_sgx_enter_enclave() needs an endbr64 > > >>> in the beginning of the function. > > >> > > >> OK. > > >> > > >> What you should do is to explain what it does and why it's needed. > > >> > > > > > > The endbr marks a branch target. Without the "no-track" prefix, if an > > > indirect call/jmp reaches a non-endbr opcode, a control-protection fault > > > is raised. Usually endbr's are inserted by the compiler. For assembly, > > > these have to be put in manually. I will add this in the commit log if > > > there is another revision. Thanks! > > > > This is close, but it's missing a detail or two that I think is > > important for someone like Jarkko trying to figure out what it means for > > his subsystem or driver. > > > > I'd probably say: > > > > ENDBR is a special new instruction for the Indirect Branch Tracking > > (IBR) component of CET. IBT prevents attacks by ensuring that (most) > > indirect branches and function calls may only land at ENDBR > > instructions. Branches that don't follow the rules will result in > > control flow (#CF) exceptions. > > > > ENDBR is a noop when IBT is unsupported or disabled. Most ENDBR > > instructions are inserted automatically by the compiler, but branch > > targets written in assembly must have ENDBR added manually, like this one. > > Thank you, this clears the whole thing a lot. > > Doesn't this mean that it could be there just as well unconditionally? Please, ignore the question (got the answer). /Jarkko
