linux-kernel - Re: [PATCH 2/2] Fix issue with dmesg.py and python 3.X

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5729ED1B.2070602@bingham.xyz>
Date:	Wed, 4 May 2016 13:37:47 +0100
From:	Kieran Bingham <kieran@...uared.org.uk>
To:	buzdelabuz2@...il.com, jan.kiszka@...mens.com
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] Fix issue with dmesg.py and python 3.X

On 04/05/16 04:12, buzdelabuz2@...il.com wrote:
> From: Dom Cote <buzdelabuz2+git@...il.com>
> 
> Replace the addition (+) of 2 python 'memoryview' objects
> with the addition of 2 'bytes' objects, convert the result
> back to memoryview.

I'm a little concerned with the text above not quite sounding like the
code below, as the two 'bytes' objects are not converted back to a
memoryview object, rather the memoryview objects are converted to
'bytes' objects (i.e. the result in log_buf) ...

Could I suggest something like the following commit-log-message? (Also
based on Jan's feedback)

---8<---
When built against Python 3, GDB differs in the return type for its
read_memory function, causing the lx-dmesg command to fail.

Now that we have an improved read_16() we can use the new
read_memoryview() abstraction to make lx-dmesg return valid data on both
current Python APIs
--->8---

(Only a suggestion of course, if you feel it should say something else
go with that)

> 
> Tested with python 3.4 and 2.7
> Tested with gdb 7.7

I have also tested with Python 3.4, 2.7 on GDB 11, and I've tested that
things still work on a wrapped log-buffer too.

Looking good.

The only final note is that because of the way Python 3 prints a
byte-stream, we end up with:


[    0.000000] b'x86/fpu: Legacy x87 FPU detected.'
instead of:
[    0.000000] x86/fpu: Legacy x87 FPU detected.

on all of the lines.

I've just done a little digging, and seen we now need to '.decode()' the
line for printing, so I'll post that as a quick patch in reply to this set.


> Signed-off-by: Dom Cote <buzdelabuz2+git@...il.com>

Tested-by: Kieran Bingham <kieran@...gham.xyz>
Reviewed-by: Kieran Bingham <kieran@...gham.xyz>


> ---
>  scripts/gdb/linux/dmesg.py | 7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/scripts/gdb/linux/dmesg.py b/scripts/gdb/linux/dmesg.py
> index 927d0d2a3145..04d6719067f2 100644
> --- a/scripts/gdb/linux/dmesg.py
> +++ b/scripts/gdb/linux/dmesg.py
> @@ -33,11 +33,12 @@ class LxDmesg(gdb.Command):
>          if log_first_idx < log_next_idx:
>              log_buf_2nd_half = -1
>              length = log_next_idx - log_first_idx
> -            log_buf = inf.read_memory(start, length)
> +            log_buf = utils.read_memoryview(inf, start, length).tobytes()
>          else:
>              log_buf_2nd_half = log_buf_len - log_first_idx
> -            log_buf = inf.read_memory(start, log_buf_2nd_half) + \
> -                inf.read_memory(log_buf_addr, log_next_idx)
> +            a = utils.read_memoryview(inf, start, log_buf_2nd_half)
> +            b = utils.read_memoryview(inf, log_buf_addr, log_next_idx)
> +            log_buf = a.tobytes() + b.tobytes()
>  
>          pos = 0
>          while pos < log_buf.__len__():
> 

-- 
Regards

Kieran Bingham