| Message ID | 822a6328-36d3-43e9-9fc4-36d01a6b9ef2@suse.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | x86/HVM: load state checking | expand |
On 16/11/2023 1:46 pm, Jan Beulich wrote: > ..., at least as reasonably feasible without making a check hook > mandatory (in particular strict vs relaxed/zero-extend length checking > can't be done early this way). > > Note that only one of the two uses of hvm_load() is accompanied with > hvm_check(). The other directly consumes hvm_save() output, which ought > to be well-formed. This means that while input data related checks don't > need repeating in the "load" function when already done by the "check" > one (albeit assertions to this effect may be desirable), domain state > related checks (e.g. has_xyz(d)) will be required in both places. > > Suggested-by: Roger Pau Monné <roger.pau@citrix.com> > Signed-off-by: Jan Beulich <jbeulich@suse.com> > --- > Do we really need all the copying involved in use of _hvm_read_entry() > (backing hvm_load_entry()? Zero-extending loads are likely easier to > handle that way, but for strict loads all we gain is a reduced risk of > unaligned accesses (compared to simply pointing into h->data[]). Pointless copying is best avoided, but it would mean that we either need to enforce proper alignment within the buffer (hard, but at least it's page aligned to start with), or __pack all of the structures so they get an alignment of 1. Not that I expect things to break in practice, but UB is UB and in some copious free time it might be nice to re-activate the unaligned checking in UBSAN on x86. > Would the hvm_sr_handlers[] better use array_access_nospec()? It's control plane only, and we have speculative protections for domU entering domctls much earlier. I wouldn't worry. > --- a/xen/arch/x86/hvm/save.c > +++ b/xen/arch/x86/hvm/save.c > @@ -291,9 +369,8 @@ int hvm_load(struct domain *d, hvm_domai > if ( !hdr ) > return -ENODATA; > > - rc = arch_hvm_load(d, hdr); > - if ( rc ) > - return rc; > + ASSERT(!arch_hvm_check(d, hdr)); You're normally the proponent of not having side effects in ASSERT()s like this. But our caller did this anyway, so why re-assert it here? ~Andrew
On 21.11.2023 23:08, Andrew Cooper wrote: > On 16/11/2023 1:46 pm, Jan Beulich wrote: >> ..., at least as reasonably feasible without making a check hook >> mandatory (in particular strict vs relaxed/zero-extend length checking >> can't be done early this way). >> >> Note that only one of the two uses of hvm_load() is accompanied with >> hvm_check(). The other directly consumes hvm_save() output, which ought >> to be well-formed. This means that while input data related checks don't >> need repeating in the "load" function when already done by the "check" >> one (albeit assertions to this effect may be desirable), domain state >> related checks (e.g. has_xyz(d)) will be required in both places. >> >> Suggested-by: Roger Pau Monné <roger.pau@citrix.com> >> Signed-off-by: Jan Beulich <jbeulich@suse.com> >> --- >> Do we really need all the copying involved in use of _hvm_read_entry() >> (backing hvm_load_entry()? Zero-extending loads are likely easier to >> handle that way, but for strict loads all we gain is a reduced risk of >> unaligned accesses (compared to simply pointing into h->data[]). > > Pointless copying is best avoided, but it would mean that we either need > to enforce proper alignment within the buffer (hard, but at least it's > page aligned to start with), or __pack all of the structures so they get > an alignment of 1. Ugly, when they're part of the public interface. > Not that I expect things to break in practice, but UB is UB and in some > copious free time it might be nice to re-activate the unaligned checking > in UBSAN on x86. The C99 standard only ever mentions "alignment appropriate for its type". I didn't even find any explicit mentioning of UB there. My understanding is that it's all down to the psABI. That, in turn, allows for unaligned accesses: "Misaligned data accesses are slower than aligned accesses but otherwise behave identically. The only exceptions are ..." >> --- a/xen/arch/x86/hvm/save.c >> +++ b/xen/arch/x86/hvm/save.c >> @@ -291,9 +369,8 @@ int hvm_load(struct domain *d, hvm_domai >> if ( !hdr ) >> return -ENODATA; >> >> - rc = arch_hvm_load(d, hdr); >> - if ( rc ) >> - return rc; >> + ASSERT(!arch_hvm_check(d, hdr)); > > You're normally the proponent of not having side effects in ASSERT()s > like this. The function could be marked pure, if it didn't log a message. I don't consider this logging a true side effect here. And I truly want the function call eliminated in release builds (i.e. I wouldn't want this to become "if() ASSERT_UNREACHABLE();"). > But our caller did this anyway, so why re-assert it here? One of the callers did, the other (hvm_copy_context_and_params()) didn't but still ought to meet the assumption. Jan
--- a/xen/arch/x86/domctl.c +++ b/xen/arch/x86/domctl.c @@ -379,6 +379,10 @@ long arch_do_domctl( if ( copy_from_guest(c.data, domctl->u.hvmcontext.buffer, c.size) != 0 ) goto sethvmcontext_out; + ret = hvm_check(d, &c); + if ( ret ) + goto sethvmcontext_out; + domain_pause(d); ret = hvm_load(d, &c); domain_unpause(d); --- a/xen/arch/x86/hvm/save.c +++ b/xen/arch/x86/hvm/save.c @@ -30,7 +30,8 @@ static void arch_hvm_save(struct domain d->arch.hvm.sync_tsc = rdtsc(); } -static int arch_hvm_load(struct domain *d, const struct hvm_save_header *hdr) +static int arch_hvm_check(const struct domain *d, + const struct hvm_save_header *hdr) { uint32_t eax, ebx, ecx, edx; @@ -55,6 +56,11 @@ static int arch_hvm_load(struct domain * "(%#"PRIx32") and restored on another (%#"PRIx32").\n", d->domain_id, hdr->cpuid, eax); + return 0; +} + +static void arch_hvm_load(struct domain *d, const struct hvm_save_header *hdr) +{ /* Restore guest's preferred TSC frequency. */ if ( hdr->gtsc_khz ) d->arch.tsc_khz = hdr->gtsc_khz; @@ -66,13 +72,12 @@ static int arch_hvm_load(struct domain * /* VGA state is not saved/restored, so we nobble the cache. */ d->arch.hvm.stdvga.cache = STDVGA_CACHE_DISABLED; - - return 0; } /* List of handlers for various HVM save and restore types */ static struct { hvm_save_handler save; + hvm_check_handler check; hvm_load_handler load; const char *name; size_t size; @@ -88,6 +93,7 @@ void __init hvm_register_savevm(uint16_t { ASSERT(typecode <= HVM_SAVE_CODE_MAX); ASSERT(hvm_sr_handlers[typecode].save == NULL); + ASSERT(hvm_sr_handlers[typecode].check == NULL); ASSERT(hvm_sr_handlers[typecode].load == NULL); hvm_sr_handlers[typecode].save = save_state; hvm_sr_handlers[typecode].load = load_state; @@ -275,6 +281,78 @@ int hvm_save(struct domain *d, hvm_domai return 0; } +int hvm_check(const struct domain *d, hvm_domain_context_t *h) +{ + const struct hvm_save_header *hdr; + int rc; + + if ( d->is_dying ) + return -EINVAL; + + /* Get at the save header, which must be first */ + hdr = hvm_point_entry(HEADER, h); + if ( !hdr ) + return -ENODATA; + + rc = arch_hvm_check(d, hdr); + if ( rc ) + return rc; + + for ( ; ; ) + { + const struct hvm_save_descriptor *desc; + hvm_check_handler handler; + + if ( h->size - h->cur < sizeof(*desc) ) + { + /* Run out of data */ + printk(XENLOG_G_ERR + "HVM restore %pd: save did not end with a null entry\n", + d); + return -ENODATA; + } + + /* Read the typecode of the next entry and check for the end-marker */ + desc = (const void *)&h->data[h->cur]; + if ( desc->typecode == HVM_SAVE_CODE(END) ) + { + /* Reset cursor for hvm_load(). */ + h->cur = 0; + return 0; + } + + /* Find the handler for this entry */ + if ( desc->typecode >= ARRAY_SIZE(hvm_sr_handlers) || + !hvm_sr_handlers[desc->typecode].name || + !hvm_sr_handlers[desc->typecode].load ) + { + printk(XENLOG_G_ERR "HVM restore %pd: unknown entry typecode %u\n", + d, desc->typecode); + return -EINVAL; + } + + /* Check the entry */ + handler = hvm_sr_handlers[desc->typecode].check; + if ( !handler ) + { + if ( desc->length > h->size - h->cur - sizeof(*desc) ) + return -ENODATA; + h->cur += sizeof(*desc) + desc->length; + } + else if ( (rc = handler(d, h)) ) + { + printk(XENLOG_G_ERR + "HVM restore %pd: failed to check %s:%u rc %d\n", + d, hvm_sr_handlers[desc->typecode].name, desc->instance, rc); + return rc; + } + + process_pending_softirqs(); + } + + /* Not reached */ +} + int hvm_load(struct domain *d, hvm_domain_context_t *h) { const struct hvm_save_header *hdr; @@ -291,9 +369,8 @@ int hvm_load(struct domain *d, hvm_domai if ( !hdr ) return -ENODATA; - rc = arch_hvm_load(d, hdr); - if ( rc ) - return rc; + ASSERT(!arch_hvm_check(d, hdr)); + arch_hvm_load(d, hdr); /* Down all the vcpus: we only re-enable the ones that had state saved. */ for_each_vcpu(d, v) @@ -304,10 +381,7 @@ int hvm_load(struct domain *d, hvm_domai { if ( h->size - h->cur < sizeof(struct hvm_save_descriptor) ) { - /* Run out of data */ - printk(XENLOG_G_ERR - "HVM%d restore: save did not end with a null entry\n", - d->domain_id); + ASSERT_UNREACHABLE(); return -ENODATA; } @@ -320,8 +394,7 @@ int hvm_load(struct domain *d, hvm_domai if ( (desc->typecode > HVM_SAVE_CODE_MAX) || ((handler = hvm_sr_handlers[desc->typecode].load) == NULL) ) { - printk(XENLOG_G_ERR "HVM%d restore: unknown entry typecode %u\n", - d->domain_id, desc->typecode); + ASSERT_UNREACHABLE(); return -EINVAL; } --- a/xen/arch/x86/include/asm/hvm/save.h +++ b/xen/arch/x86/include/asm/hvm/save.h @@ -103,6 +103,8 @@ static inline unsigned int hvm_load_inst * restoring. Both return non-zero on error. */ typedef int (*hvm_save_handler) (struct vcpu *v, hvm_domain_context_t *h); +typedef int (*hvm_check_handler)(const struct domain *d, + hvm_domain_context_t *h); typedef int (*hvm_load_handler) (struct domain *d, hvm_domain_context_t *h); @@ -140,6 +142,7 @@ size_t hvm_save_size(struct domain *d); int hvm_save(struct domain *d, hvm_domain_context_t *h); int hvm_save_one(struct domain *d, unsigned int typecode, unsigned int instance, XEN_GUEST_HANDLE_64(uint8) handle, uint64_t *bufsz); +int hvm_check(const struct domain *d, hvm_domain_context_t *h); int hvm_load(struct domain *d, hvm_domain_context_t *h); #endif /* __XEN_HVM_SAVE_H__ */
..., at least as reasonably feasible without making a check hook mandatory (in particular strict vs relaxed/zero-extend length checking can't be done early this way). Note that only one of the two uses of hvm_load() is accompanied with hvm_check(). The other directly consumes hvm_save() output, which ought to be well-formed. This means that while input data related checks don't need repeating in the "load" function when already done by the "check" one (albeit assertions to this effect may be desirable), domain state related checks (e.g. has_xyz(d)) will be required in both places. Suggested-by: Roger Pau Monné <roger.pau@citrix.com> Signed-off-by: Jan Beulich <jbeulich@suse.com> --- Do we really need all the copying involved in use of _hvm_read_entry() (backing hvm_load_entry()? Zero-extending loads are likely easier to handle that way, but for strict loads all we gain is a reduced risk of unaligned accesses (compared to simply pointing into h->data[]). Would the hvm_sr_handlers[] better use array_access_nospec()? --- v2: New.