search for: endpage

On Wed, Feb 15, 2017 at 10:29:41PM +0000, Richard W.M. Jones wrote: > Yes, or even how about this (not tried it): > > while (off <= h->endpages - 0x1000) { > ... > } In fact this doesn't work either :-( I'll have another look at this tomorrow morning. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is...

OK, I ended up turning the warning off. It appears from the info file that the warning is about GCC not being able to make an optimization, not a bug in the code. However I do have a more substantial problem with the patch. By checking the offset against h->endpages, we're using an untrusted field supplied to us by the hive, which means that a crafted hive could cause us to walk through memory past the end of the file -- a security issue. So I think the test should be using h->size with the additional check for off >= h->endpages, as in the exis...

On Wed, 2017-02-15 at 22:35 +0000, Richard W.M. Jones wrote: > On Wed, Feb 15, 2017 at 10:29:41PM +0000, Richard W.M. Jones wrote: > > Yes, or even how about this (not tried it): > > > > while (off <= h->endpages - 0x1000) { > >   ... > > } > > In fact this doesn't work either :-( > > I'll have another look at this tomorrow morning. > > Rich. > Yep, GCC7 complains about that off could overflow over SIZE_MAX when incremented with 0x1000 and could cause infinite...

...re not listed on the WxWidgets documentation page, but they are in the wxWidgets source file, as being public virtual methods. Examples: StartDoc //virtual method overriding the DC::StartDoc EndDoc //virtual method overriding the DC::EndDoc StartPage //virtual method overridng the DC::StartPage EndPage //virtual method overriding the DC::EndPage If I need trial and error I can do that, but thought maybe you followed a certain pattern... Thanks, Zach

...p turning the warning off.  It appears from the > > info file that the warning is about GCC not being able to make > > an optimization, not a bug in the code. > > > > However I do have a more substantial problem with the patch. > > By checking the offset against h->endpages, we're using an > > untrusted > > field supplied to us by the hive, which means that a crafted hive > > could cause us to walk through memory past the end of the file -- > > a security issue. > > > > So I think the test should be using h->size with the a...

...s); > - goto error; > + > + DEBUG (2, > + "page not found at expected offset 0x%zx, " > + "seeking until one is found or EOF is reached", > + off); > + > + int found = 0; > + while (off < h->endpages) { GCC 7 warns: handle.c: In function 'hivex_open': handle.c:236:13: error: missed loop optimization, the loop counter may overflow [-Werror=unsafe-loop-optimizations] while (off < h->endpages) { ^ I suspect this means that GCC might try to turn this into an in...

...know of :-) However I don't see any other simple way to > silence that GCC7 warning and it seems harmless that way to me > (besides > the fact that the loop will have to make more iterations) So I've found a way to keep offsetting by 4k and keep GCC7 happy: while (off < h->endpages) { if (off + 0x1000 > off) off += 0x1000; else break; // off would overflow Is this acceptable? Regards, Dawid

...; > > +             "page not found at expected offset 0x%zx, " > > > +             "seeking until one is found or EOF is reached", > > > +             off); > > > + > > > +      int found = 0; > > > +      while (off < h->endpages) { > > > > GCC 7 warns: > > > > handle.c: In function 'hivex_open': > > handle.c:236:13: error: missed loop optimization, the loop counter > > may overflow [-Werror=unsafe-loop-optimizations] > >        while (off < h->endpages) { > >...

...[i], t, len, key, str) == -1) + vtor->value_other (h, opaque, node, values[i], + t, len, key, str) == -1) goto error; free (str); str = NULL; break; @@ -1774,9 +1810,11 @@ allocate_page (hive_h *h, size_t allocation_hint) ssize_t extend = h->endpages + nr_4k_pages * 4096 - h->size; if (h->msglvl >= 2) { - fprintf (stderr, "allocate_page: current endpages = 0x%zx, current size = 0x%zx\n", + fprintf (stderr, "allocate_page: current endpages = 0x%zx," + " current size = 0x%zx\n",...

...nable_execute_stack(void* addr) >> > { >> > - >> > +#ifndef _WIN32 >> > #if __APPLE__ >> > /* On Darwin, pagesize is always 4096 bytes */ >> > const uintptr_t pageSize = 4096; >> > @@ -54,6 +58,14 @@ >> > unsigned char* endPage = (unsigned >> char*)((p+TRAMPOLINE_SIZE+pageSize) & pageAlignMask); >> > size_t length = endPage - startPage; >> > (void) mprotect((void *)startPage, length, PROT_READ | PROT_WRITE | >> PROT_EXEC); >> > +#else >> >> Why not simply #elif de...

...> > +      DEBUG (2, > > +             "page not found at expected offset 0x%zx, " > > +             "seeking until one is found or EOF is reached", > > +             off); > > + > > +      int found = 0; > > +      while (off < h->endpages) { > > GCC 7 warns: > > handle.c: In function 'hivex_open': > handle.c:236:13: error: missed loop optimization, the loop counter > may overflow [-Werror=unsafe-loop-optimizations] >        while (off < h->endpages) { >              ^ > > I suspect thi...

...e any other simple way to > > silence that GCC7 warning and it seems harmless that way to me > > (besides > > the fact that the loop will have to make more iterations) > > So I've found a way to keep offsetting by 4k and keep GCC7 happy: > > while (off < h->endpages) { > if (off + 0x1000 > off) > off += 0x1000; > else > break; // off would overflow > > Is this acceptable? Yes, or even how about this (not tried it): while (off <= h->endpages - 0x1000) { ... } Rich. -- Richard Jones, Virtualization Group, Red Hat h...

...> > OK, I ended up turning the warning off. It appears from the > info file that the warning is about GCC not being able to make > an optimization, not a bug in the code. > > However I do have a more substantial problem with the patch. > By checking the offset against h->endpages, we're using an untrusted > field supplied to us by the hive, which means that a crafted hive > could cause us to walk through memory past the end of the file -- > a security issue. > > So I think the test should be using h->size with the additional > check for off >=...

...amp; pageAlignMask); ^ /home/pranav/smack-project/llvm/src/projects/compiler-rt/lib/enable_execute_stack.c:54:27: error: cast to 'unsigned char *' from smaller integer type 'unsigned int' [-Werror,-Wint-to-pointer-cast] unsigned char* endPage = (unsigned char*)((p+TRAMPOLINE_SIZE+pageSize) & pageAlignMask); ^ 2 errors generated. ... On gcc --version I get the following output: gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3 My operating system is a Ubuntu 12.04.1 LTS. On typing uname -a I get:...

... "page not found at expected offset 0x%zx, " > > > > +             "seeking until one is found or EOF is reached", > > > > +             off); > > > > + > > > > +      int found = 0; > > > > +      while (off < h->endpages) { > > > > > > GCC 7 warns: > > > > > > handle.c: In function 'hivex_open': > > > handle.c:236:13: error: missed loop optimization, the loop > > > counter > > > may overflow [-Werror=unsafe-loop-optimizations] > > >...

Hello Richard As discussed in the IRC channel, when merging a moderately large reg file (~35MB) to a hiv file (~118 MB); hivex generates a huge hiv file (~580 MB). These changes address that by creating a list of unallocated blocks and reassigning unused blocks. I used https://github.com/msuhanov/regf/blob/master/Windows%20registry%20file%20format%20specification.md as a reference for the

The following patches address issues when dealing with hives that have corrupted data in them but are otherwise readable/writable. Those were found on some rather rare Windows installations that seem to work fine but current hivex fails to even open. Those patches change hivex to simply log and ignore such "corrupted" regions instead of aborting because the caller might be looking at

...> ^ > /home/pranav/smack-project/llvm/src/projects/compiler-rt/lib/enable_execute_stack.c:54:27: error: cast to 'unsigned char *' from smaller integer type 'unsigned int' > [-Werror,-Wint-to-pointer-cast] > unsigned char* endPage = (unsigned char*)((p+TRAMPOLINE_SIZE+pageSize) & pageAlignMask); > ^ > 2 errors generated. > ... > > On gcc --version I get the following output: > gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3 > My operating system is a Ubuntu 12.04.1...

This is, hopefully, a full fix for handling of li-records. See: https://bugzilla.redhat.com/show_bug.cgi?id=717583 https://bugzilla.redhat.com/show_bug.cgi?id=987463 Rich.

...^ > > > /home/pranav/smack-project/llvm/src/projects/compiler-rt/lib/enable_execute_stack.c:54:27: > error: cast to 'unsigned char *' from smaller integer type 'unsigned int' > > [-Werror,-Wint-to-pointer-cast] > > unsigned char* endPage = (unsigned > char*)((p+TRAMPOLINE_SIZE+pageSize) & pageAlignMask); > > ^ > > 2 errors generated. > > ... > > > > On gcc --version I get the following output: > > gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3 > > M...