On 03/03/2015 07:02 PM, Konrad Rzeszutek Wilk wrote:> On Tue, Mar 03, 2015 at 06:38:20PM +0300, Andrey Ryabinin wrote: >> On 03/03/2015 05:16 PM, Konrad Rzeszutek Wilk wrote: >>> On Tue, Mar 03, 2015 at 04:15:06PM +0300, Andrey Ryabinin wrote: >>>> On 03/03/2015 12:40 PM, Luis R. Rodriguez wrote: >>>>> Andrey, >>>>> >>>>> I believe that on Xen we should disable kasan, would like confirmation >>>> >>>> I guess Xen guests won't work with kasan because Xen guests doesn't setup shadow >>>> (kasan_map_early_shadow() is not called in xen guests). >>>> >>>> Disabling kasan for Xen in Kconfig is undesirable because that will disable kasan >>>> for allmodconfig and allyesconfig builds, but I don't see other option for now. >>> >>> Was there an bug reported for this? It would be good to CC the maintainers >>> of Xen on that sort of thing. >>> >> >> There was no report for this. I just looked at Xen code because of this Luis's mail >> and I don't see how it could work with kasan. > > Ahh. >> Fixing this might be not trivial. We need to setup shadow memory before any kasan instrumented >> function will run. >> This is like with -fstack-protector (you need to setup gdt before calling any stack protected function). > > If it is like that - then just using what had to be implemented > for the stack protection as a template ought to pave most of the > work? >Probably. I think I could make this work. However, I won't be able to work on this until the end of the next week.
On Wed, Mar 4, 2015 at 6:36 AM, Andrey Ryabinin <a.ryabinin at samsung.com> wrote:> On 03/03/2015 07:02 PM, Konrad Rzeszutek Wilk wrote: >> If it is like that - then just using what had to be implemented >> for the stack protection as a template ought to pave most of the >> work? > > Probably. I think I could make this work. > However, I won't be able to work on this until the end of the next week.While a solution is likely possible here I'd like for us to notice how two features have gone now under our nose for Xen on v4.0 which have issues. Proactive maintainer reviews would detect these issues but we can't bet on these, and testing is just as reactive and slow. I'm hinting we keep our eyes out for an architectural solution that would avoid these issues. Don't ask me what that is just yet... Luis
On Wed, Mar 04, 2015 at 05:47:03PM -0800, Luis R. Rodriguez wrote:> On Wed, Mar 4, 2015 at 6:36 AM, Andrey Ryabinin <a.ryabinin at samsung.com> wrote: > > On 03/03/2015 07:02 PM, Konrad Rzeszutek Wilk wrote: > >> If it is like that - then just using what had to be implemented > >> for the stack protection as a template ought to pave most of the > >> work? > > > > Probably. I think I could make this work. > > However, I won't be able to work on this until the end of the next week. > > While a solution is likely possible here I'd like for us to notice how > two features have gone now under our nose for Xen on v4.0 which have > issues. Proactive maintainer reviews would detect these issues but we > can't bet on these, and testing is just as reactive and slow. I'mHmm, I see you saying 'Proactive maintainer review would detect' these but that assumes that the maintainer would even be copied on these patches? None of the Xen maintainers were copied on this. And while we all strive to be pro-active I have to remind you maintainers are usually swamped.> hinting we keep our eyes out for an architectural solution that would > avoid these issues. Don't ask me what that is just yet...Keep in mind that a lot of these issues get resolved during merge window thanks to the resiliancy of Boris monitoring these tests with an sharp eye! After all that is what merge windows are - things break during them.> > Luis