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: <f15515fa-f89d-7e9b-6d4f-cf6c49b43687@huaweicloud.com>
Date:   Wed, 9 Aug 2023 15:05:07 +0800
From:   "Leizhen (ThunderTown)" <thunder.leizhen@...weicloud.com>
To:     Sergey Senozhatsky <senozhatsky@...omium.org>
Cc:     Steven Rostedt <rostedt@...dmis.org>,
        Petr Mladek <pmladek@...e.com>,
        John Ogness <john.ogness@...utronix.de>,
        linux-kernel@...r.kernel.org, Zhen Lei <thunder.leizhen@...wei.com>
Subject: Re: [PATCH 2/2] hexdump: add a new dump prefix
 DUMP_PREFIX_ADDRESS_LOW16



On 2023/8/9 12:10, Sergey Senozhatsky wrote:
> On (23/08/08 15:52), Leizhen (ThunderTown) wrote:
>>>> I find the "before" much easier to read than the "after".
>>
>> I added the boot option no_hash_pointers, so "before" can print the
>> address. Otherwise, just print the 32-bit hash value, as shown below:
> 
> 
>> [   14.872153] dump memory at sp=ffff800080903aa0:
> 
> This line is not guaranteed to be printed. If you get
> "** N printk messages dropped **" instead then the
> ADDRESS_LOW16 math doesn't work.

Anyone is vulnerable in the face of nature. Even DUMP_PREFIX_ADDRESS,
without the preface, no one know what's dumped. In any case,
DUMP_PREFIX_ADDRESS_LOW16 has its own unique value in this ecosystem.
The only regret is that it has a slightly longer name than others.
Maybe it could be DUMP_PREFIX_ADDRLOW or something.

By the way, would you consider changing %p to %px in case DUMP_PREFIX_ADDRESS?

> 
>> Actually, I added DUMP_PREFIX_ADDRESS_LOW16 because of another scene:
>> slab kmalloc-512 start ffff3b3c0094e800 pointer offset 168 size 512
>> e888: 00400000 00000000 000f7704 00000000
>> e898: 000f7704 00000000 12345678 00000000
>> e8a8: 00000000 00000000 00000000 00000000
>> e8b8: 9abcdef0 00000000 00507dd0 00000000
>>
>> Here, the start address ffff3b3c0094e800 of slab object is printed by %px,
>> the address of the error data is at p=ffff3b3c0094e8a8 = ffff3b3c0094e800 + offset 168.
>> To locate the problem, dump up to 64 bytes centered on 'p'.
> .
> 

-- 
Regards,
  Zhen Lei

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ