search for: endpages

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 exist...

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 l...

Nick, I had a few minutes so I implemented the WxPrinterDC class tonight, and I have a question on Virtual Methods. Is there a general rule of thumb to follow? Should they be implemented in the wxRuby header and source files, or should I ignore them? They are not listed on the WxWidgets documentation page, but they are in the wxWidgets source file, as being public virtual methods. Examples:

...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 ad...

...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 inf...

...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",...

2013/5/30 Ruben Van Boxem <vanboxem.ruben at gmail.com> > 2013/5/25 Aaron Ballman <aaron at aaronballman.com> > >> On Fri, May 24, 2013 at 5:53 PM, Ruben Van Boxem >> <vanboxem.ruben at gmail.com> wrote: >> > Hi, >> > >> > I submitted this patch a long while ago, together with a bunch of other >> > changes (some of which got

...> > +      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...

...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 ht...

...> > 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...

Hi, I am trying to build llvm along with clang and compiler-rt. When I run make, I am getting the following compilation error (I tried compiling llvm-3.2, which is what I need for my project, but also tried llvm-3.3 and the current llvm source from the git repository). ... COMPILE: clang_linux/full-x86_64/x86_64:

... "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

You can disable -Werror by adding the cmake flag -DLLVM_ENABLE_WERROR=OFF, which should let it just ignore that (that's also the default, so you must have turned it on somewhere) On Jul 31, 2013, at 13:09 , Pranav Garg <pranav.garg2107 at gmail.com> wrote: > Hi, > > I am trying to build llvm along with clang and compiler-rt. When I run make, I am getting the following

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.

Hi, I see that ENABLE_WERROR is being set to off (the default value) in the config.log in the llvm build. However on grepping for WERROR in the compiler-rt folder I get the following output: pranav at pranav:~/smack-project/llvm-3.4/src/projects/compiler-rt$ grep -Rin WERROR * lib/asan/tests/CMakeLists.txt:38: -Werror lib/asan/asan_malloc_mac.cc:253:// This function is currently unused, and we