On Tue, Mar 11, 2025 at 4:18 PM Paolo Bonzini <pbonz...@redhat.com> wrote: > > > > Il lun 10 mar 2025, 23:18 Alistair Francis <alistai...@gmail.com> ha scritto: >> >> On Tue, Mar 11, 2025 at 3:34 AM Paolo Bonzini <pbonz...@redhat.com> wrote: >> > >> > On Fri, Mar 7, 2025 at 1:45 AM Alistair Francis <alistai...@gmail.com> >> > wrote: >> > > I'm not convinced that this is the thing that we should be checking >> > > for. If someone can corrupt the migration data for an attack there are >> > > better things to change then the MXL >> > >> > In principle you could have code that uses 2 << MXL to compute the >> > size of a memcpy, or something like that... never say never. :) >> >> But couldn't they also change the PC at that point and execute >> malicious code? Or MTVEC or anything else? > > > The point is exploiting the host, not the guest.
Ah! Ok, I misunderstood. > >> It just seems like this check doesn't actually provide any security. >> >> In the future we will want to merge misa_mxl and misa_mxl_max and this >> patch just makes that a little bit harder, for no real gains that I >> can see. >> >> > Do you prefer turning all the priv_ver, vext_ver, misa_mxl, >> > misa_ext_mask fields into VMSTATE_UNUSED? That would also be okay. >> >> I think we do want to migrate them, they contain important information. > > > They are constant though, aren't they? Properties aren't migrated, they are > set on the command line of the destination. I didn't think about properties not being migrated. At which point I think it does then make sense to make them VMSTATE_UNUSED Alistair
