>>> On 29.08.16 at 04:47, wrote:
> On Wed, Aug 24, 2016 at 04:01:53AM -0600, Jan Beulich wrote:
>> >>> On 19.08.16 at 12:20, wrote:
>> > @@ -1403,12 +1437,12 @@ void __init noreturn __start_xen(unsigned long
>> > mbi_p)
>> >
>> > if ( !opt_smep )
>> > setup_clear_cpu_cap(X86_FEAT
On Wed, Aug 24, 2016 at 04:01:53AM -0600, Jan Beulich wrote:
> >>> On 19.08.16 at 12:20, wrote:
> > Changes in v3:
> > * Fix boot options.
> > * Fix CR4 & mmu_cr4_features operations.
> > * Disable SMEP/SMAP for Dom0.
> > * Commit message refinement.
>
> Several of my comments on v3 did not get t
>>> On 19.08.16 at 12:20, wrote:
> Changes in v3:
> * Fix boot options.
> * Fix CR4 & mmu_cr4_features operations.
> * Disable SMEP/SMAP for Dom0.
> * Commit message refinement.
Several of my comments on v3 did not get taken care of (neither in
code nor verbally). I'm not going to repeat them her
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.
A 32-bit PV guest will suffer unknown SMEP/SMAP page fault when guest
kernel attempt