On Tue, Sep 20, 2016 at 12:53:32AM -0600, Jan Beulich wrote:
> >>> On 20.09.16 at 04:29, wrote:
> > Sorry for the late response, I saw the this patch was merged but soon
> > got reverted, and the revert message says this patch is still buggy.
> >
> > I would be most grateful if you would point ou
>>> On 20.09.16 at 04:29, wrote:
> Sorry for the late response, I saw the this patch was merged but soon
> got reverted, and the revert message says this patch is still buggy.
>
> I would be most grateful if you would point out the buggy part of this
> patch and the reason why revert it.
Well, I
Hi Jan,
Sorry for the late response, I saw the this patch was merged but soon
got reverted, and the revert message says this patch is still buggy.
I would be most grateful if you would point out the buggy part of this
patch and the reason why revert it.
Thanks,
-He
_
>>> On 05.09.16 at 07:17, wrote:
> @@ -1403,12 +1451,16 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>
> if ( !opt_smep )
> setup_clear_cpu_cap(X86_FEATURE_SMEP);
> -if ( cpu_has_smep )
> +else if ( opt_smep == 1 )
> +__set_bit(X86_FEATURE_XEN_SMEP, boot
>>> On 05.09.16 at 07:17, wrote:
> SMEP/SMAP is a security feature to prevent kernel executing/accessing
> user address involuntarily, any such behavior will lead to a page fault.
>
> SMEP/SMAP is open (in CR4) for both Xen and HVM guest in earlier code.
> SMEP/SMAP bit set in Xen CR4 would enfor
SMEP/SMAP is a security feature to prevent kernel executing/accessing
user address involuntarily, any such behavior will lead to a page fault.
SMEP/SMAP is open (in CR4) for both Xen and HVM guest in earlier code.
SMEP/SMAP bit set in Xen CR4 would enforce security checking for 32-bit
PV guest whi
