On Thu, Sep 11, 2014 at 2:31 AM, Baoquan He wrote:
> On 09/10/14 at 07:41am, Kees Cook wrote:
>> On Wed, Sep 10, 2014 at 7:30 AM, Vivek Goyal wrote:
>> > So I would suggest that test and repost the other patch with proper
>> > changelog
>> > and that might be sufficient for now. Only other thing
On 09/10/14 at 07:41am, Kees Cook wrote:
> On Wed, Sep 10, 2014 at 7:30 AM, Vivek Goyal wrote:
> > So I would suggest that test and repost the other patch with proper
> > changelog
> > and that might be sufficient for now. Only other thing we will need is
> > Kees's patch for avoiding setup data
On Wed, Sep 10, 2014 at 11:27:16PM +0800, Baoquan He wrote:
> On 09/10/14 at 11:05am, Vivek Goyal wrote:
> > On Wed, Sep 10, 2014 at 07:41:38AM -0700, Kees Cook wrote:
> > > On Wed, Sep 10, 2014 at 7:30 AM, Vivek Goyal wrote:
> > > > So I would suggest that test and repost the other patch with pro
On 09/10/14 at 11:05am, Vivek Goyal wrote:
> On Wed, Sep 10, 2014 at 07:41:38AM -0700, Kees Cook wrote:
> > On Wed, Sep 10, 2014 at 7:30 AM, Vivek Goyal wrote:
> > > So I would suggest that test and repost the other patch with proper
> > > changelog
> > > and that might be sufficient for now. Onl
On 09/10/14 at 11:04am, Vivek Goyal wrote:
> On Wed, Sep 10, 2014 at 10:53:34PM +0800, Baoquan He wrote:
> > On 09/10/14 at 10:30am, Vivek Goyal wrote:
> > > In case of kdump we will have to pass nokaslr, as we don't want kernel
> > > to move as it could stomp over other things we have loaded.
> >
On Wed, Sep 10, 2014 at 07:41:38AM -0700, Kees Cook wrote:
> On Wed, Sep 10, 2014 at 7:30 AM, Vivek Goyal wrote:
> > So I would suggest that test and repost the other patch with proper
> > changelog
> > and that might be sufficient for now. Only other thing we will need is
> > Kees's patch for av
On Wed, Sep 10, 2014 at 10:53:34PM +0800, Baoquan He wrote:
> On 09/10/14 at 10:30am, Vivek Goyal wrote:
> > On Wed, Sep 10, 2014 at 03:21:15PM +0800, Baoquan He wrote:
>
>
> > > In fact, I think below checking will be clearer and works too.
> > >
> > >
> > > static void handle_relocations(vo
On 09/10/14 at 10:30am, Vivek Goyal wrote:
> On Wed, Sep 10, 2014 at 03:21:15PM +0800, Baoquan He wrote:
> > In fact, I think below checking will be clearer and works too.
> >
> >
> > static void handle_relocations(void *output, unsigned long output_len)
> > {
> >
> > ...
> >
> > #if CONFIG
On Wed, Sep 10, 2014 at 7:30 AM, Vivek Goyal wrote:
> So I would suggest that test and repost the other patch with proper changelog
> and that might be sufficient for now. Only other thing we will need is
> Kees's patch for avoiding setup data regions in kaslr.
If someone can confirm that my patc
On Wed, Sep 10, 2014 at 03:21:15PM +0800, Baoquan He wrote:
> On 09/09/14 at 03:28pm, Vivek Goyal wrote:
> > On Tue, Sep 09, 2014 at 08:53:29AM -0700, Kees Cook wrote:
>
> > > I still think this needs a test for the 32-bit case, since IUIC, it
> > > requires relocations unconditionally.
> >
> >
On Wed, Sep 10, 2014 at 02:10:35PM +0800, Baoquan He wrote:
[..]
> > > diff --git a/arch/x86/boot/compressed/misc.c
> > > b/arch/x86/boot/compressed/misc.c
> > > index 57ab74d..887f404 100644
> > > --- a/arch/x86/boot/compressed/misc.c
> > > +++ b/arch/x86/boot/compressed/misc.c
> > > @@ -230,8 +
On 09/09/14 at 03:28pm, Vivek Goyal wrote:
> On Tue, Sep 09, 2014 at 08:53:29AM -0700, Kees Cook wrote:
> > I still think this needs a test for the 32-bit case, since IUIC, it
> > requires relocations unconditionally.
>
> [ CC hpa ]
>
> Bao, for modifications in this area, I would recommend CC
On 09/09/14 at 08:53am, Kees Cook wrote:
>
> > Hi Kees,
> >
> > Checking handle_relocations() again, I just didn't notice it's mandatory
> > to do the relocations handling in i386. So in this function delta is
> > checked to see if it's a kaslr relocation handling. This might be a
> > little confu
On Tue, Sep 9, 2014 at 12:28 PM, Vivek Goyal wrote:
> On Tue, Sep 09, 2014 at 08:53:29AM -0700, Kees Cook wrote:
>> On Mon, Sep 8, 2014 at 11:24 PM, Baoquan He wrote:
>> > On 09/05/14 at 10:11am, Kees Cook wrote:
>> >> I don't think this is correct. If you look at a02150610776 ("x86,
>> >> relocs
On Tue, Sep 09, 2014 at 08:53:29AM -0700, Kees Cook wrote:
> On Mon, Sep 8, 2014 at 11:24 PM, Baoquan He wrote:
> > On 09/05/14 at 10:11am, Kees Cook wrote:
> >> I don't think this is correct. If you look at a02150610776 ("x86,
> >> relocs: Move ELF relocation handling to C"), we always did reloca
On Mon, Sep 8, 2014 at 11:24 PM, Baoquan He wrote:
> On 09/05/14 at 10:11am, Kees Cook wrote:
>> I don't think this is correct. If you look at a02150610776 ("x86,
>> relocs: Move ELF relocation handling to C"), we always did relocations
>> on 32-bit when CONFIG_RELOCATABLE was set, so I think this
On 09/05/14 at 10:11am, Kees Cook wrote:
> I don't think this is correct. If you look at a02150610776 ("x86,
> relocs: Move ELF relocation handling to C"), we always did relocations
> on 32-bit when CONFIG_RELOCATABLE was set, so I think this will fail
> badly on 32-bit. 64-bit only needs relocatio
On 09/05/14 at 10:11am, Kees Cook wrote:
> On Fri, Sep 5, 2014 at 7:08 AM, Baoquan He wrote:
> > kaslr's action is splitted into 2 parts. The 1st is getting available memory
> > slots and randomly choose the kernel relocation address. After decompression
> > of kernel to the chosen place, the 2nd
On Fri, Sep 5, 2014 at 7:08 AM, Baoquan He wrote:
> kaslr's action is splitted into 2 parts. The 1st is getting available memory
> slots and randomly choose the kernel relocation address. After decompression
> of kernel to the chosen place, the 2nd part begin to check if kaslr has got
> a relocati
kaslr's action is splitted into 2 parts. The 1st is getting available memory
slots and randomly choose the kernel relocation address. After decompression
of kernel to the chosen place, the 2nd part begin to check if kaslr has got
a relocation address, and will do the relocations handling if yes.
H
20 matches
Mail list logo
