Re: [Xen-devel] kasan_map_early_shadow() on Xen
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. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] kasan_map_early_shadow() on Xen
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). ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] kasan_map_early_shadow() on Xen
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. > from someone on xen-devel though. Here's the thing though -- if true > -- I'd like to do it *properly*, where *properly* means addressing a > bit of architecture. A simple Kconfig slap seems rather reactive. I'd > like to address a way to properly ensure we don't run into this and > other similar issues in the future. The CR4 shadow issue was another > recent example issue, also introduced via v4.0 [0]. We can't keep > doing this reactively. > > Let's go down the rabbit hole for a bit. HAVE_ARCH_KASAN will be > selected on x86 when: > > if X86_64 && SPARSEMEM_VMEMMAP > > Now Xen should not have SPARSEMEM_VMEMMAP but PVOPs' goal is to enable > distributions to be able to have a single binary kernels and let the > rest be figured out, so we can't just disable SPARSEMEM_VMEMMAP for > Xen alone, we want to build Xen.. or part of Xen and perhaps keep > SPARSEMEM_VMEMMAP, and only later figure things out. > > How do we do this cleanly and avoid future reactive measures? If the > answer is not upon us, I'd like to at least highlight the issue so > that in case we do come up with something its no surprise PVOPs is > falling short for that single binary pipe dream right now. > > [0] https://lkml.org/lkml/2015/2/23/328 > > Luis > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86 spinlock: Fix memory corruption on completing completions
On 02/06/2015 07:15 PM, Linus Torvalds wrote: > On Fri, Feb 6, 2015 at 7:20 AM, Sasha Levin wrote: >> >> Can we modify it slightly to avoid potentially accessing invalid memory: > > So I think there's a race with that. > > And I'll warn you: the kernel does do speculative reads of memory that > might be invalid, not just in places like this. See the comment in > get_user_huge_page() for example, where we knowingly do speculative > reads, but hide it if DEBUG_PAGEALLOC is set. > > More commonly, CONFIG_DCACHE_WORD_ACCESS is very much about doing > speculative reads. Now, that access is hidden inside an asm, so KASan > won't see it, but there might well be others. > > You probably don't see them very much just because they are so rarely > a problem, and most of the time it's not to other processes stack but > to allocated structures where freeing takes long enough to basically > hide any small race.. > > In other words: I suspect it would be good to instead just teach KASan > about "this is a speculative read" and just suppress the warning for > those instead. > We can suppress warnings by wrapping such speculative reads with kasan_disable_current()/kasan_enable_current() calls. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
