On 2/2/2016 2:05 PM, Andrew Cooper wrote:
Xen and PV guests share the virtual address space, in exactly the same
way as a native kernel and its userspace. PV guests can map pages at
0. Therefore, if Xen were to accidentally follow a NULL pointer, it
may not result in a pagefault. (Hardware mech
On 02/02/16 11:39, Corneliu ZUZU wrote:
> On 2/2/2016 12:52 PM, Jan Beulich wrote:
>>> NULLing the pointers would cause things like rtc_deinit() to always
>>> blow
>>> up when it followed the NULL pointer.
>>>
>>> IMO, we should unconditionally always NULL pointers when freeing a
>>> pointer which
>>> On 02.02.16 at 12:39, wrote:
> On 2/2/2016 12:52 PM, Jan Beulich wrote:
>>> NULLing the pointers would cause things like rtc_deinit() to always blow
>>> up when it followed the NULL pointer.
>>>
>>> IMO, we should unconditionally always NULL pointers when freeing a
>>> pointer which isn't in l
On 2/2/2016 12:52 PM, Jan Beulich wrote:
NULLing the pointers would cause things like rtc_deinit() to always blow
up when it followed the NULL pointer.
IMO, we should unconditionally always NULL pointers when freeing a
pointer which isn't in local scope. It would make issues such as these
compl
On 02/02/16 10:52, Jan Beulich wrote:
On 02.02.16 at 11:48, wrote:
>> On 02/02/16 10:43, Jan Beulich wrote:
>> On 01.02.16 at 18:56, wrote:
For safety, NULL out the pointers after freeing them, in an attempt to make
mistakes more obvious in the future.
>>> Except that NULLing i
>>> On 02.02.16 at 11:48, wrote:
> On 02/02/16 10:43, Jan Beulich wrote:
> On 01.02.16 at 18:56, wrote:
>>> For safety, NULL out the pointers after freeing them, in an attempt to make
>>> mistakes more obvious in the future.
>> Except that NULLing isn't really adding that much safety, and we'
On 02/02/16 10:43, Jan Beulich wrote:
On 01.02.16 at 18:56, wrote:
>> For safety, NULL out the pointers after freeing them, in an attempt to make
>> mistakes more obvious in the future.
> Except that NULLing isn't really adding that much safety, and we'd
> be better off poisoning such pointer
>>> On 01.02.16 at 18:56, wrote:
> For safety, NULL out the pointers after freeing them, in an attempt to make
> mistakes more obvious in the future.
Except that NULLing isn't really adding that much safety, and we'd
be better off poisoning such pointers. Nevertheless ...
> Signed-off-by: Andrew
On 02/02/16 08:00, Corneliu ZUZU wrote:
> On 2/1/2016 7:56 PM, Andrew Cooper wrote:
>> c/s 428607a "x86: shrink 'struct domain', was already PAGE_SIZE"
>> introduced a
>> use-after-free error during domain destruction, because of the order
>> in which
>> timers are torn down.
>>
>>(XEN) Xen cal
On 2/1/2016 7:56 PM, Andrew Cooper wrote:
c/s 428607a "x86: shrink 'struct domain', was already PAGE_SIZE" introduced a
use-after-free error during domain destruction, because of the order in which
timers are torn down.
(XEN) Xen call trace:
(XEN)[] spinlock.c#check_lock+0x1e/0x40
(
c/s 428607a "x86: shrink 'struct domain', was already PAGE_SIZE" introduced a
use-after-free error during domain destruction, because of the order in which
timers are torn down.
(XEN) Xen call trace:
(XEN)[] spinlock.c#check_lock+0x1e/0x40
(XEN)[] _spin_lock+0x11/0x52
(XEN)[] v
11 matches
Mail list logo
