Re: [RFC][PATCH 0/3] arm64 relaxed ABI

[Kevin Brodsky]

On 25/02/2019 18:02, Szabolcs Nagy wrote:
> On 25/02/2019 16:57, Catalin Marinas wrote:
> > On Tue, Feb 19, 2019 at 06:38:31PM +0000, Szabolcs Nagy wrote:
> > > i think these rules work for the cases i care about, a more
> > > tricky question is when/how to check for the new syscall abi
> > > and when/how the TCR_EL1.TBI0 setting may be turned off.
> > I don't think turning TBI0 off is critical (it's handy for PAC with
> > 52-bit VA but then it's short-lived if you want more security features
> > like MTE).
> yes, i made a mistake assuming TBI0 off is
> required for (or at least compatible with) MTE.
>
> if TBI0 needs to be on for MTE then some of my
> analysis is wrong, and i expect TBI0 to be on
> in the foreseeable future.
>
> > > consider the following cases (tb == top byte):
> > >
> > > binary 1: user tb = any, syscall tb = 0
> > >    tbi is on, "legacy binary"
> > >
> > > binary 2: user tb = any, syscall tb = any
> > >    tbi is on, "new binary using tb"
> > >    for backward compat it needs to check for new syscall abi.
> > >
> > > binary 3: user tb = 0, syscall tb = 0
> > >    tbi can be off, "new binary",
> > >    binary is marked to indicate unused tb,
> > >    kernel may turn tbi off: additional pac bits.
> > >
> > > binary 4: user tb = mte, syscall tb = mte
> > >    like binary 3, but with mte, "new binary using mte"
> so this should be "like binary 2, but with mte".
>
> > >    does it have to check for new syscall abi?
> > >    or MTE HWCAP would imply it?
> > >    (is it possible to use mte without new syscall abi?)
> > I think MTE HWCAP should imply it.
> >
> > > in userspace we want most binaries to be like binary 3 and 4
> > > eventually, i.e. marked as not-relying-on-tbi, if a dso is
> > > loaded that is unmarked (legacy or new tb user), then either
> > > the load fails (e.g. if mte is already used? or can we turn
> > > mte off at runtime?) or tbi has to be enabled (prctl? does
> > > this work with pac? or multi-threads?).
> > We could enable it via prctl. That's the plan for MTE as well (in
> > addition maybe to some ELF flag).
> >
> > > as for checking the new syscall abi: i don't see much semantic
> > > difference between AT_HWCAP and AT_FLAGS (either way, the user
> > > has to check a feature flag before using the feature of the
> > > underlying system and it does not matter much if it's a syscall
> > > abi feature or cpu feature), but i don't see anything wrong
> > > with AT_FLAGS if the kernel prefers that.
> > The AT_FLAGS is aimed at capturing binary 2 case above, i.e. the
> > relaxation of the syscall ABI to accept tb = any. The MTE support will
> > have its own AT_HWCAP, likely in addition to AT_FLAGS. Arguably,
> > AT_FLAGS is either redundant here if MTE implies it (and no harm in
> > keeping it around) or the meaning is different: a tb != 0 may be checked
> > by the kernel against the allocation tag (i.e. get_user() could fail,
> > the tag is not entirely ignored).
> >
> > > the discussion here was mostly about binary 2,
> > That's because passing tb != 0 into the syscall ABI is the main blocker
> > here that needs clearing out before merging the MTE support. There is,
> > of course, a variation of binary 1 for MTE:
> >
> > binary 5: user tb = mte, syscall tb = 0
> >
> > but this requires a lot of C lib changes to support properly.
> yes, i don't think we want to do that.
>
> but it's ok to have both syscall tbi AT_FLAGS and MTE HWCAP.
>
> > > but for
> > > me the open question is if we can make binary 3/4 work.
> > > (which requires some elf binary marking, that is recognised
> > > by the kernel and dynamic loader, and efficient handling of
> > > the TBI0 bit, ..if it's not possible, then i don't see how
> > > mte will be deployed).
> > If we ignore binary 3, we can keep TBI0 = 1 permanently, whether we have
> > MTE or not.
> >
> > > and i guess on the kernel side the open question is if the
> > > rules 1/2/3/4 can be made to work in corner cases e.g. when
> > > pointers embedded into structs are passed down in ioctl.
> > We've been trying to track these down since last summer and we came to
> > the conclusion that it should be (mostly) fine for the non-weird memory
> > described above.
> i think an interesting case is when userspace passes
> a pointer to the kernel and later gets it back,
> which is why i proposed rule 4 (kernel has to keep
> the tag then).
>
> but i wonder what's the right thing to do for sp
> (user can malloc thread/sigalt/makecontext stack
> which will be mte tagged in practice with mte on)
> does tagged sp work? should userspace untag the
> stack memory before setting it up as a stack?
> (but then user pointers to that allocation may get
> broken..)

Tagged SP does work, and it is actually a good idea (it avoids using the default tag 
for the stack). It would be quite easy for the kernel to tag the initial SP and the 
stack on execve(). For other stacks, it is up to userspace, as you say, and would be 
made easier by making it possible to choose how a mapping should be tagged by the 
kernel via a new mmap() flag. Some software that makes too many assumptions on the 
address of stack variables will be disturbed by a tagged SP, but this should be 
fairly rare.

In any case, I don't think this impacts this ABI proposal (beyond the fact that 
passing tagged pointers to the stack needs to be allowed).

Kevin