linux-kernel - Re: [PATCH v2 0/5] beautify EFI memmap logs

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: <CAKv+Gu-dTApubxij8U3P93BnWot+x7Vy+QNE+xBMdU5xoOSBgA@mail.gmail.com>
Date:	Wed, 3 Sep 2014 15:27:28 +0200
From:	Ard Biesheuvel <ard.biesheuvel@...aro.org>
To:	Laszlo Ersek <lersek@...hat.com>
Cc:	Ingo Molnar <mingo@...nel.org>,
	"linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"x86@...nel.org" <x86@...nel.org>,
	"linux-ia64@...r.kernel.org" <linux-ia64@...r.kernel.org>,
	Matt Fleming <matt.fleming@...el.com>,
	Mark Salter <msalter@...hat.com>
Subject: Re: [PATCH v2 0/5] beautify EFI memmap logs

On 3 September 2014 15:24, Laszlo Ersek <lersek@...hat.com> wrote:
> On 09/03/14 15:01, Ard Biesheuvel wrote:
>> On 3 September 2014 13:32, Laszlo Ersek <lersek@...hat.com> wrote:
>>> changes in v2:
>>> - explain with examples how the log's appearance changes, in patches 3-5
>>>   [Ingo]
>>>
>>> v1 blurb:
>>>
>>>> It's a pain to analyze EFI memmap logs while debugging, especially to
>>>> verify the memory types (an enum) and the memory attributes (a
>>>> bitmap). This series renders those columns human-readable, and unifies
>>>> their formatting between x86, ia64 and arm64.
>>>
>>
>> Tested-by: Ard Biesheuvel <ard.biesheuvel@...aro.org>
>> (on arm64 only)
>>
>> +1 for aligning between architectures
>> +1 for cleaning up the output to make it more readable
>>
>> The only thing I am not entirely convinced about is printing all those
>> memory attributes: is it really so interesting to know that region X
>> /can/ be configured as writeback, write through, write combining etc
>> etc, as most regions seem to support most attributes, yet it tells you
>> nothing about what the kernel ends up doing with that information. In
>> the arm64 case, for instance, all MEMORY_WB ranges are mapped
>> writeback cached, and everything else is mapped uncached.
>
> You don't need these attributes spelled out when you're not debugging.
> In that case, either build without CONFIG_EFI_DEBUG (on x86 and ia64),
> or don't pass uefi_debug=1 (on arm64).
>
> When you're debugging however, you need every bit of info you can get.
> For example, assume a tricky bug in exactly that part of the arm64 code
> that you just described above. You'll be flip-flopping between the
> kernel source and the original, pristine memory map dump. It's much
> easier to ignore a few words / columns in the log (even: cut it out with
> a script or interactively) than to read bitmaps in hex (or to decode
> them in a script). I know because I grew to hate these hex-encoded
> attributes and dec-encoded enum constants when I was developing S3 for
> OVMF, and fighting the memmap.
>
> A good analogue is ACPI debugging in the kernel. The ACPI subsystem
> comes with a very elaborate heap of switches, facility bitmaps, log
> levels, and so on. The end result is that it is faster to add printks to
> your suspect location(s) in ACPI, rebuild, retest, repeat, than to learn
> to use the acpi debug flags. (And I did the former when I was recently
> fixing a bug in the RHEL-6 kernel, in the intersection of ACPI and EFI.)
>
> So yes, I think that this detailed format is preferable.
>

OK, you've convinced me :-)

Acked-by: Ard Biesheuvel <ard.biesheuvel@...aro.org>

Cheers,
Ard.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/