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. 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).
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?
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.