[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 03 Mar 2015 18:38:20 +0300
From: Andrey Ryabinin <a.ryabinin@...sung.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
Cc: "Luis R. Rodriguez" <mcgrof@...e.com>,
Jeremy Fitzhardinge <jeremy@...p.org>,
Rusty Russell <rusty@...tcorp.com.au>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Andy Lutomirski <luto@...capital.net>,
Chris Wright <chrisw@...s-sol.org>,
xen-devel@...ts.xenproject.org,
Boris Ostrovsky <boris.ostrovsky@...cle.com>,
virtualization@...ts.linux-foundation.org,
Alok Kataria <akataria@...are.com>
Subject: 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).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists