linux-kernel - Re: [BISECTED] v4.15-rc: Boot regression on x86

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: <CA+55aFyQchgcmZFJqYD3jpka82G76SYs3dZka5v9_3q5=tJR2w@mail.gmail.com>
Date:   Tue, 9 Jan 2018 11:57:11 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Christian König <christian.koenig@....com>
Cc:     Bjorn Helgaas <bhelgaas@...gle.com>,
        Aaro Koskinen <aaro.koskinen@....fi>,
        Andy Shevchenko <andy.shevchenko@...il.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-pci@...r.kernel.org,
        Boris Ostrovsky <boris.ostrovsky@...cle.com>,
        Juergen Gross <jgross@...e.com>
Subject: Re: [BISECTED] v4.15-rc: Boot regression on x86_64/AMD

On Tue, Jan 9, 2018 at 11:31 AM, Christian König
<christian.koenig@....com> wrote:
>>
>> For example, was there a reason for that random 756GB address? Is the
>> limit of the particular AMD 64-bit bar perhaps at the 1TB mark (and
>> that "res->end" value is because "close to it, but not at the top")?
>
> That is actually a hardware limit documented in the BIOS and Kernel
> developers guide for AMD CPUs
> (https://support.amd.com/TechDocs/49125_15h_Models_30h-3Fh_BKDG.pdf).
>
> I should probably add a comment explaining this.

Ok, good. So at least some of those values have reasons.

And yes, documenting it would be great.

>> A starting point like "halfway to from the hardware limit" would
>> actually be a better reason. Or just "we picked an end-point, let's
>> pick a starting point that gives us a _sufficient_ - but not excessive
>> - window".
>
>
> Well that is exactly what the 256GB patch was doing.

Ahh, so 0xbd00000000ull is basically 256GB from the end point, and the
end point is basically specified by hardware.

So yes, I think that's a starting point that can at least be
explained: let's try to make it something "big enough" (and 256GB
seems to be big enough).

Of course, since this is all "pick a random number", maybe that breaks
something _else_.

We do traditionally have a very similar issue for the 32-bit PCI
starting address, where we used to have tons of issues with "we don't
know all resources, we want to try to come up with a range that is out
of the way".

There we try to find a big enough gap in th e820 memory map
(e820_search_gap()), and the end result is pci_mem_start (which is
then exposed as PCIBIOS_MIN_MEM to the PCI resource allocation).

If worst comes to worst, maybe we should look at having something
similar for the full 64-bit range.

             Linus