On 12/03/2018 15:02, Vitaly Kuznetsov wrote:
>
> +/*
> + * Currently, the only way for processes to change their FS/GS base is to
> call
> + * ARCH_SET_FS/GS prctls and these reflect changes they make in task->thread.
> + * There are, however, additional considerations:
> + *
> + * There is X86_BUG_NULL_SEG: on some CPUs writing '0' to FS/GS selectors
> zeroes
> + * the base and on some it doesn't, we need to check for that
> + * (see save_base_legacy()).
> + *
> + * When FSGSBASE extensions are enabled userspace processes will be able to
> + * change their FS/GS bases without kernel intervention. save_fsgs() will
> + * have to be updated to actually read FS and GS bases with RD[FG,GS]BASE
> + * instructions.
> + */
> +void save_current_fsgs(void)
> +{
> + save_fsgs(current);
> +}
> +EXPORT_SYMBOL_GPL(save_current_fsgs);
We don't really need save_fsgs in KVM though. We already do the
savesegment ourselves, and we know Intel CPUs don't have
X86_BUG_NULL_SEG. So this:
savesegment(fs, vmx->host_state.fs_sel);
if (!(vmx->host_state.fs_sel & 7)) {
vmcs_write16(HOST_FS_SELECTOR, vmx->host_state.fs_sel);
vmx->host_state.fs_reload_needed = 0;
} else {
vmcs_write16(HOST_FS_SELECTOR, 0);
vmx->host_state.fs_reload_needed = 1;
}
savesegment(gs, vmx->host_state.gs_sel);
...
could probably become simply:
savesegment(fs, vmx->host_state.fs_sel);
/*
* When FSGSBASE extensions are enabled, this will have to use
* RD{FS,GS}BASE instead of accessing current, and the
* corresponding WR{FS,GS}BASE should be done unconditionally,
* even if fs_reload_needed (resp. gs_ldt_reload_needed) is 1.
*/
if (vmx->host_state.fs_sel <= 3) {
vmcs_write16(HOST_FS_SELECTOR, vmx->host_state.fs_sel);
vmcs_write16(HOST_FS_BASE, current->thread.fsbase);
vmx->host_state.fs_reload_needed = 0;
} else {
vmcs_write16(HOST_FS_SELECTOR, 0);
vmcs_write16(HOST_FS_BASE, 0);
vmx->host_state.fs_reload_needed = 1;
}
savesegment(gs, vmx->host_state.gs_sel);
...
?
Paolo
