linux-kernel - Re: [PATCH v2 1/4] dt-bindings: reserved-memory: Document "active" property

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]

Date:   Fri, 25 Sep 2020 16:21:17 +0300
From:   Dmitry Osipenko <digetx@...il.com>
To:     Robin Murphy <robin.murphy@....com>,
        Thierry Reding <thierry.reding@...il.com>
Cc:     Joerg Roedel <joro@...tes.org>, Rob Herring <robh+dt@...nel.org>,
        Frank Rowand <frowand.list@...il.com>,
        Will Deacon <will@...nel.org>,
        iommu@...ts.linux-foundation.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        "linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>
Subject: Re: [PATCH v2 1/4] dt-bindings: reserved-memory: Document "active"
 property

25.09.2020 15:39, Robin Murphy пишет:
...
>> IIRC, in the past Robin Murphy was suggesting to read out hardware state
>> early during kernel boot in order to find what regions are in use by
>> hardware.
> 
> I doubt I suggested that in general, because I've always firmly believed
> it to be a terrible idea. I've debugged too many cases where firmware or
> kexec has inadvertently left DMA running and corrupted kernel memory, so
> in general we definitely *don't* want to blindly trust random hardware
> state. Anything I may have said in relation to Qualcomm's fundamentally
> broken hypervisor/bootloader setup should not be considered outside that
> specific context ;)
> 
> Robin.
> 
>> I think it should be easy to do for the display controller since we
>> could check clock and PD states in order to decide whether DC's IO could
>> be accessed and then read out the FB pointer and size. I guess it should
>> take about hundred lines of code.

The active DMA is indeed very dangerous, but it's a bit less dangerous
in a case of read-only DMA.

I got another idea of how we could benefit from the active display
hardware. Maybe we could do the following:

1. Check whether display is active

2. Allocate CMA that matches the FB size

3. Create identity mapping for the CMA

4. Switch display framebuffer to our CMA

5. Create very early simple-framebuffer out of the CMA

6. Once Tegra DRM driver is loaded, it will kick out the simple-fb, and
thus, release temporal CMA and identity mapping.

This will provide us with a very early framebuffer output and it will
work on all devices out-of-the-box!