Hi Pratyush
On 01/25/17 at 10:14am, Pratyush Anand wrote:
> Currently all the p_paddr of PT_LOAD headers are assigned to 0, which is
> not true and could be misleading, since 0 is a valid physical address.
I do not know the history of /proc/kcore, so a question is why the
p_addr was set as 0, if t
Hi Dave,
On Wednesday 25 January 2017 11:59 AM, Dave Young wrote:
Hi Pratyush
On 01/25/17 at 10:14am, Pratyush Anand wrote:
Currently all the p_paddr of PT_LOAD headers are assigned to 0, which is
not true and could be misleading, since 0 is a valid physical address.
I do not know the history
On Mon, Jan 30, 2017 at 11:00 AM, Pratyush Anand wrote:
> CCing Andrew and Kees for their review comments.
>
>
> On Wednesday 25 January 2017 10:14 AM, Pratyush Anand wrote:
>> Currently all the p_paddr of PT_LOAD headers are assigned to 0, which is
>> not true and could be misleading, since 0 is
On Tuesday 14 February 2017 03:55 AM, Kees Cook wrote:
On Mon, Jan 30, 2017 at 11:00 AM, Pratyush Anand wrote:
CCing Andrew and Kees for their review comments.
On Wednesday 25 January 2017 10:14 AM, Pratyush Anand wrote:
Currently all the p_paddr of PT_LOAD headers are assigned to 0, which
Hi Andrew/Kees,
On Tuesday 14 February 2017 07:16 AM, Pratyush Anand wrote:
Well, CONFIG_PROC_KCORE is a generalized root KASLR exposure (though
there are lots of such exposures). Why is the actual physical address
needed? Can this just report the virtual address instead? Then the
tool can buil
CC Eric too.
On 02/13/17 at 02:25pm, Kees Cook wrote:
> On Mon, Jan 30, 2017 at 11:00 AM, Pratyush Anand wrote:
> > CCing Andrew and Kees for their review comments.
> >
> >
> > On Wednesday 25 January 2017 10:14 AM, Pratyush Anand wrote:
> >> Currently all the p_paddr of PT_LOAD headers are assig
