On Thu, Mar 12, 2015 at 5:48 PM, Ian Campbell <ian.campb...@citrix.com> wrote:
> On Thu, 2015-03-12 at 17:02 +0100, Tamas K Lengyel wrote: > > > > > > On Thu, Mar 12, 2015 at 4:56 PM, Ian Campbell > > <ian.campb...@citrix.com> wrote: > > On Thu, 2015-03-12 at 16:44 +0100, Tamas K Lengyel wrote: > > > > > > > > > On Thu, Mar 12, 2015 at 4:40 PM, Julien Grall > > > <julien.gr...@linaro.org> wrote: > > > Hi Ian, > > > > > > On 12/03/15 15:27, Ian Campbell wrote: > > > >> Currently, check_type_get_page emulate only the > > check for > > > 2). So you may > > > >> end up to allow Xen writing in read-only mapping > > (from the > > > Stage 1 POV). > > > >> This was XSA-98. > > > > > > > > XSA-98 was purely about stage-2 permissions (e.g. > > read-only > > > grants). The > > > > fact that the resulting patch also checks stage-1 > > > permissions is not a > > > > security property AFAICT. > > > > > > XSA-98 was for both... Without checking stage-1 > > permission a > > > userspace > > > which can issue an hypercall may be able to write > > into > > > read-only kernel > > > space. Whoops. > > > > > > > > > Userspace is able to issue hypercall? > > > > > > Via ioctls on /proc/xen/privcmd, yes. It's how the toolstack > > talks to > > Xen... > > > > > > Well, that is not the userspace issuing the hypercall, its a kernel > > module issuing the hypercall on behalf of a process ;) > > But the vaddrs etc in there are userspace controlled and the kernel does > not validate them. > > Ian. > Right, it's a bit splitting hairs and my point was just that the kernel is always in the middle and theoretically could implement input validation and access control as well. Tamas
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
