[PATCHv4 14/17] arm64: uaccess: remove set_fs()

[Catalin Marinas]

On Tue, Nov 17, 2020 at 10:57:40AM +0000, Mark Rutland wrote:
> On Tue, Nov 17, 2020 at 10:54:18AM +0000, Catalin Marinas wrote:
> > On Tue, Nov 17, 2020 at 10:44:54AM +0000, Mark Rutland wrote:
> > > On Mon, Nov 16, 2020 at 05:40:48PM +0000, Catalin Marinas wrote:
> > > > On Fri, Nov 13, 2020 at 12:49:34PM +0000, Mark Rutland wrote:
> > > > > We no longer need to flip UAO to access kernel memory under KERNEL_DS,
> > > > > and head.S unconditionally clears UAO for all kernel configurations via
> > > > > an ERET in init_kernel_el. Thus, we don't need to dynamically flip UAO,
> > > > > nor do we need to context-switch it. However, we do need to clear UAO
> > > > > (and set PAN) during SDEI entry.
> > > > 
> > > > If the kernel never sets the UAO bit, why do we need to clear it during
> > > > SDEI entry?
> > > 
> > > The fear was taking an SDEI event from a VM which had UAO set, with the
> > > SDEI FW not clearing UAO.
> > > 
> > > That might not happen in practice because while the spec implies that
> > > could happen, TF-A currently generates a new PSTATE from scratch, and
> > > going forward the spec will be aligned with regular exception entry
> > > rules for PSTATE (so UAO will be cleared automatically).
> > 
> > Does this requirement apply retrospectively or it only for the future
> > SDEI specs?
> 
> It applies from the current spec, but note that TF-A has always
> generated a new PSTATE (with UAO clear).

And we can assume that TF-A is the only implementation generating SDEI.

> > > So we can probably drop the clearing of UAO if you prefer.
> > 
> > I don't like clearing UAO specifically. There may be other PSTATE bits
> > in the future we don't know or care about and that are left set by
> > firmware. If we don't trust firmware to give a clean PSTATE, can we
> > reset it with an ERET?
> 
> In future we should get the new behaviour, so I think we should be fine
> there. If we can't trust PSTATE at all, then we're not necessarily able
> to perform an ERET anyway.
> 
> ... which I think means I'm arguing in favour of deleting the clearing
> of UAO, if you're happy with that?

Yes, I'm fine with that. That means that you can also get rid of
cpu_has_uao().

Could we apply the same logic to SDEI+PAN?

-- 
Catalin