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: <YWATQgGOFQIlLOlV@zn.tnic>
Date:   Fri, 8 Oct 2021 11:45:38 +0200
From:   Borislav Petkov <bp@...en8.de>
To:     Mika Westerberg <mika.westerberg@...ux.intel.com>
Cc:     Werner Sembach <wse@...edocomputers.com>, benoitg@...us.ca,
        bhelgaas@...gle.com, hpa@...or.com, juhapekka.heikkila@...il.com,
        linux-kernel@...r.kernel.org, mingo@...hat.com, tglx@...utronix.de,
        x86@...nel.org
Subject: Re: [PATCH RESEND] x86/resource: Do not exclude regions that are
 marked as MMIO in EFI memmap

On Fri, Oct 08, 2021 at 12:23:31PM +0300, Mika Westerberg wrote:
> Hi,
> 
> On Fri, Oct 08, 2021 at 10:55:49AM +0200, Werner Sembach wrote:
> > Is there any update on this matter? Also happens on discrete Thunderbolt 4 chips:
> > https://bugzilla.kernel.org/show_bug.cgi?id=214259
> 
> AFAICT no updates.
> 
> @Bjorn, x86 maintainers,
> 
> If there are no alternatives can we get this patch merged so that people
> don't need to carry out-of-tree patches to get their systems working?

Just my 2ยข from briefly skimming over this:

So this reads yet again as BIOS is to blame but what else is new?

"All in all, I think we can fix this by modifying
arch_remove_reservations() to check the EFI type as well and if it is
EFI_MEMORY_MAPPED_IO skip the clipping in that case."

And this like we should trust EFI to mark those regions properly, which
is more of the same but in different color.

That original commit talks about windoze doing a different allocation
scheme and thus not trusting the untrustworthy firmware anyway and that
sounds like something we should do too. But WTH do I know?!

So I'd prefer if Bjorn chimed in here.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ