linux-kernel - Re: BGRT Pointer in System RAM

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: <CALCETrUMrztJ1aTfvfMZyOSRFhDM52Fa3pSS8EuW3ByYGMNMpg@mail.gmail.com>
Date:	Mon, 15 Jul 2013 16:24:23 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Josh Triplett <josh@...htriplett.org>
Cc:	Parag Warudkar <parag.lkml@...il.com>,
	LKML <linux-kernel@...r.kernel.org>, linux-acpi@...r.kernel.org
Subject: Re: BGRT Pointer in System RAM

On Mon, Jul 15, 2013 at 4:20 PM, Josh Triplett <josh@...htriplett.org> wrote:
> On Mon, Jul 15, 2013 at 04:08:13PM -0700, Andy Lutomirski wrote:
>> On Mon, Jul 15, 2013 at 4:04 PM, Josh Triplett <josh@...htriplett.org> wrote:
>> > On Mon, Jul 15, 2013 at 01:28:36PM -0700, Andy Lutomirski wrote:
>> >>
>> >> Interesting.  My BGRT says:
>> >>
>> >> [028h 0040   8]                Image Address : 0D06801800000001
>> >>
>> >> If I reverse the high and low 32-bit dwords, then I get an address in
>> >> system RAM.
>> >
>> > Does that address in RAM start with a BMP header?
>>
>> No idea.  I'd presumably have to modify the driver to find out --
>> otherwise something else will overwrite it.
>
> You could boot with a mem= command-line argument that reserves that
> memory.

I'll see what I can do.

>
>> > Because that would be *special*.  I don't think it's worth trying to
>> > cope with that bug; better to just write off the BGRT as invalid if the
>> > BIOS can't get endianness right.
>> >
>> > In theory we could guess at that bug if the unmangled address points to
>> > a location in RAM starting with a BMP header.  In practice, let's not; a
>> > missing BGRT is a purely cosmetic issue, and BIOS vendors can learn to
>> > get that one right if they want to see their logo during Linux boot.
>> > This won't break fastboot support, it just breaks fancy crossfades from
>> > the BIOS logo to a Linux desktop or splash.
>>
>> FWIW, the address that my BIOS gives is non-canonical.  Maybe that's
>> good enough.
>
> What do you mean by "non-canonical".

Brainfart.  I'm confusing physical and virtual addresses.  More
usefully, the bogus address from my BIOS is too large -- it's way
above the highest e820 spot (and I'm pretty sure it exceeds the
maximum address that my CPU can address).  Maybe that would be a
decent heuristic to use to avoid trying to follow the pointer.

>
>> > So, a "firmware bug" message in dmesg seems sufficent for that case.  We
>> > do need to handle the case of a valid pointer into memory that e820
>> > calls system RAM, as well as the case of a valid pointer into memory
>> > reserved for the BIOS or similar, but not the case of an invalid
>> > pointer.
>>
>> Is the efi_bgrt code called early enough that data in system RAM will
>> still be there?
>
> In theory, it should always point to data in EFI's "reserved until after
> boot time" memory.
>
> - Josh Triplett
--
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/