On Tue, 4 Feb 2020 11:37:42 +0100
Thomas Huth <thuth@xxxxxxxxxx> wrote:
[...]
> > ---
> > arch/s390/kernel/pgm_check.S | 4 +-
> > arch/s390/mm/fault.c | 87
> > ++++++++++++++++++++++++++++++++++++ 2 files changed, 89
> > insertions(+), 2 deletions(-)
> [...]
> > +void do_non_secure_storage_access(struct pt_regs *regs)
> > +{
> > + unsigned long gaddr = regs->int_parm_long &
> > __FAIL_ADDR_MASK;
> > + struct gmap *gmap = (struct gmap *)S390_lowcore.gmap;
> > + struct uv_cb_cts uvcb = {
> > + .header.cmd = UVC_CMD_CONV_TO_SEC_STOR,
> > + .header.len = sizeof(uvcb),
> > + .guest_handle = gmap->se_handle,
> > + .gaddr = gaddr,
> > + };
> > + int rc;
> > +
> > + if (get_fault_type(regs) != GMAP_FAULT) {
> > + do_fault_error(regs, VM_READ | VM_WRITE,
> > VM_FAULT_BADMAP);
> > + WARN_ON_ONCE(1);
> > + return;
> > + }
> > +
> > + rc = uv_make_secure(gmap, gaddr, &uvcb, 0);
> > + if (rc == -EINVAL && uvcb.header.rc != 0x104)
> > + send_sig(SIGSEGV, current, 0);
> > +}
>
> What about the other rc beside 0x104 that could happen here? They go
> unnoticed?
no, they are handled in the uv_make_secure, and return an appropriate
error code. 104 in this context still indicates that things were already
how we wanted, so we consider it a success here. e.g. for unpack it is
not considered a success. that's why we check for -EINVAL (which is the
generic error) and then check for the specific rc
a cleaner solution perhaps would have been to split uv_make_secure to
handle rc 0x104 differently, but I didn't want to duplicate the code
here.
Claudio
