On 06/09/17 13:44, gengdongjiu wrote: > > > On 2017/9/6 20:30, Vladimir Murzin wrote: >> On 06/09/17 13:14, gengdongjiu wrote: >>> >>> >>> On 2017/9/6 20:00, Vladimir Murzin wrote: >>>> On 06/09/17 11:35, gengdongjiu wrote: >>>>> Vladimir, >>>>> >>>>> On 2017/9/6 17:41, Vladimir Murzin wrote: >>>>>> Can you please elaborate on cases where PAN is not enabled? >>>>> >>>>> I mean the informal private usage, For example, he disabled the PAN >>>>> dynamically to let kernel space to access the user space. >>>>> After he dynamic disabled the PAN, then switched to guest OS. after >>>>> return to host. he found the PAN stage is modified. >>>>> Of cause this is not a formal usage, in our host kernel, it is always >>>>> enabled, no dynamic change, but I means it may exist such cases. >>>>> >>>>> >>>> >>>> So, in short, there is no real issue with PAN, right? What about UAO? >>> For the PAN, if host OS dynamically enable/disable PAN should have issue. >>> Do you think that is not a issue as above description? >>> >>> "host OS dynamically disable the PAN, but after go back from the guest OS, >>> The PAN is unexpectedly enabled" >> >> Do you see effect of "PAN is unexpectedly enabled"? > In fact I did not encounter this case, but I think it can exist. > I think if host OS dynamically disable PAN, it wants the host kernel access > the user space address space not through copy_to/from_user API. > Now if it is unexpectedly enabled, when host kernel still accesses the user > space address, it will happen MMU fault exception.
And this is expected! The only allowed channel for kernel <-> user is uaccess API. I guess that you have test (and that great!) which violates that rule (for testing purpose, why not?) and now you are trying to fit kernel into it... Cheers Vladimir > > >> >> Cheers >> Vladimir >> >>> >>>> >>>> Cheers >>>> Vladimir >>>> >>>> . >>>> >>> >>> >> >> >> . >> > >
