similar to: [PATCH 1/2] lib: write: Remove unused variable.

It was brought to my attention that dumping a registry hive causes a lot of time spent in disk I/O activity because iconv_open() and iconv_close() are called for every key. Every iconv_open() call causes /usr/lib/.../gconv/$ENCODING.so to be opened and mapped. The iconv_t handles are now cached in the hive_h struct; they are opened on-demand and re-used. On my ~10 year old Lenovo T60, I have

--- lib/hivex-internal.h | 8 +++++--- lib/utf16.c | 11 +++++++---- 2 files changed, 12 insertions(+), 7 deletions(-) diff --git a/lib/hivex-internal.h b/lib/hivex-internal.h index 4135f58..64fd49a 100644 --- a/lib/hivex-internal.h +++ b/lib/hivex-internal.h @@ -268,11 +268,13 @@ extern size_t * _hivex_return_offset_list (offset_list *list); extern void _hivex_print_offset_list

On Fri, Feb 09, 2018 at 01:52:52AM +0100, Hilko Bengen wrote: > It was brought to my attention that dumping a registry hive causes a > lot of time spent in disk I/O activity because iconv_open() and > iconv_close() are called for every key. Every iconv_open() call causes > /usr/lib/.../gconv/$ENCODING.so to be opened and mapped. > > The iconv_t handles are now cached in the

It was brought to my attention that dumping a registry hive causes a lot of time spent in disk I/O activity because iconv_open() and iconv_close() are called for every key. Every iconv_open() call causes /usr/lib/.../gconv/$ENCODING.so to be opened and mapped. The iconv_t handles are now cached in the hive_h struct; they are opened on-demand and re-used. On my ~10 year old Lenovo T60, I have

This patch assumes that iconv doesn't actually modify the input buffer, even though it is declared as char *. --- lib/hivex-internal.h | 6 +++--- lib/utf16.c | 9 +++++---- 2 files changed, 8 insertions(+), 7 deletions(-) diff --git a/lib/hivex-internal.h b/lib/hivex-internal.h index 7a548c0..6bc8638 100644 --- a/lib/hivex-internal.h +++ b/lib/hivex-internal.h @@ -268,9 +268,9 @@

--- lib/hivex-internal.h | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/lib/hivex-internal.h b/lib/hivex-internal.h index f391b98..d7ce339 100644 --- a/lib/hivex-internal.h +++ b/lib/hivex-internal.h @@ -125,7 +125,19 @@ struct ntreg_hbin_block { struct ntreg_nk_record { int32_t seg_len; /* length (always -ve because used) */ char id[2];

On Tuesday 31 December 2013 14:27:11 Richard W.M. Jones wrote: > This patch assumes that iconv doesn't actually modify the > input buffer, even though it is declared as char *. > --- > [...] > @@ -51,10 +51,11 @@ _hivex_recode (char *input_encoding, const char > *input, size_t input_len, errno = err; > return NULL; > } > - char *inp = input; > + const

Hi, this small series cherry-picks a couple of the portability fixes recently done in libguestfs to hivex. There should be no actual change on Linux. Thanks, -- Pino Pino Toscano (2): normalize iconv handling ruby: fix detection of ruby library bootstrap | 1 + configure.ac | 8 +++++++- lib/utf16.c | 3 +-- 3 files changed, 9 insertions(+), 3 deletions(-) -- 1.9.3

On Windows, there exist at least two APIs for dealing with the Registry: The Win32 API (RegCreateKeyA, RegCreateKeyW, etc.) works with null-terminated ASCII or UTF-16 strings. The native API (ZwCreateKey, etc.), on the other hand works with UTF-16 strings that are stored as buffers+length and may contain null characters. Malware authors have been relying on the Win32 API's inability to

--- lib/hivex-internal.h | 6 +++++- lib/node.c | 7 +------ lib/utf16.c | 5 ++--- lib/value.c | 7 +------ 4 files changed, 9 insertions(+), 16 deletions(-) diff --git a/lib/hivex-internal.h b/lib/hivex-internal.h index d7ce339..4135f58 100644 --- a/lib/hivex-internal.h +++ b/lib/hivex-internal.h @@ -268,7 +268,11 @@ extern size_t * _hivex_return_offset_list

[ This patch depends on the cross-architecture ELF cleanup patch. ] This series updates the boot protocol to 2.07 and uses it to implement paravirtual booting. This allows the bootloader to tell the kernel what kind of hardware/pseudo-hardware environment it's coming up under, and the kernel can use the appropriate boot sequence code. Specifically: - Update the boot protocol to 2.07, which

[ This patch depends on the cross-architecture ELF cleanup patch. ] This series updates the boot protocol to 2.07 and uses it to implement paravirtual booting. This allows the bootloader to tell the kernel what kind of hardware/pseudo-hardware environment it's coming up under, and the kernel can use the appropriate boot sequence code. Specifically: - Update the boot protocol to 2.07, which

On Sun, Nov 24, 2013 at 11:25:53PM +0100, Hilko Bengen wrote: > --- > lib/write.c | 49 ++++++++++++++++++++++++++++++++++--------------- > 1 file changed, 34 insertions(+), 15 deletions(-) > > diff --git a/lib/write.c b/lib/write.c > index dbb8292..72b1f8a 100644 > --- a/lib/write.c > +++ b/lib/write.c > @@ -608,9 +608,17 @@ hivex_node_add_child (hive_h *h,

--- lib/write.c | 50 +++++++++++++++++++++++++++++++++++--------------- 1 file changed, 35 insertions(+), 15 deletions(-) diff --git a/lib/write.c b/lib/write.c index dbb8292..8c4dd8e 100644 --- a/lib/write.c +++ b/lib/write.c @@ -608,9 +608,17 @@ hivex_node_add_child (hive_h *h, hive_node_h parent, const char *name) return 0; } + size_t recoded_name_len; + int use_utf16 = 0; +

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.

--- lib/write.c | 49 ++++++++++++++++++++++++++++++++++--------------- 1 file changed, 34 insertions(+), 15 deletions(-) diff --git a/lib/write.c b/lib/write.c index dbb8292..72b1f8a 100644 --- a/lib/write.c +++ b/lib/write.c @@ -608,9 +608,17 @@ hivex_node_add_child (hive_h *h, hive_node_h parent, const char *name) return 0; } + size_t recoded_name_len; + int use_utf16 = 0; +

This series updates the boot protocol to 2.07 and uses it to implement paravirtual booting. This allows the bootloader to tell the kernel what kind of hardware/pseudo-hardware environment it's coming up under, and the kernel can use the appropriate boot sequence code. Specifically: - Update the boot protocol to 2.07, which adds fields to specify the hardware subarchitecture and some

This series updates the boot protocol to 2.07 and uses it to implement paravirtual booting. This allows the bootloader to tell the kernel what kind of hardware/pseudo-hardware environment it's coming up under, and the kernel can use the appropriate boot sequence code. Specifically: - Update the boot protocol to 2.07, which adds fields to specify the hardware subarchitecture and some

This series updates the boot protocol to 2.07 and uses it to implement paravirtual booting. This allows the bootloader to tell the kernel what kind of hardware/pseudo-hardware environment it's coming up under, and the kernel can use the appropriate boot sequence code. Specifically: - Update the boot protocol to 2.07, which adds fields to specify the hardware subarchitecture and some

>>That boot_params.hdr.code32_start field is probably either invalid (bad reloc or something else causing the bootloader to >>calculate the wrong address) or valid but the thing it thinks it is pointing to wasn't loaded (missing PT_LOAD etc.). >boot_params.hdr.code32_start field is valid :) It is 0x100000, like expected > >Then I suspect that that segment isn't being