[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAB=NE6WxNfxsqnv9MBpoL1=umdNReUCbM_dnxROjeY9J1Q-U_Q@mail.gmail.com>
Date: Wed, 4 Mar 2015 17:47:03 -0800
From: "Luis R. Rodriguez" <mcgrof@...e.com>
To: Andrey Ryabinin <a.ryabinin@...sung.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@...cle.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 Wed, Mar 4, 2015 at 6:36 AM, Andrey Ryabinin <a.ryabinin@...sung.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
--
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