linux-kernel - Re: [RFC/PATCH] of: Mark property::value as const

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: <CAL_JsqJDaa+ozCTyS6M_1BP-sk3g5T2wQK+5DLTPWBKyp=AMeA@mail.gmail.com>
Date:   Thu, 23 Feb 2017 07:39:53 -0600
From:   Rob Herring <robh+dt@...nel.org>
To:     Stephen Boyd <stephen.boyd@...aro.org>
Cc:     Frank Rowand <frowand.list@...il.com>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: Re: [RFC/PATCH] of: Mark property::value as const

On Mon, Feb 13, 2017 at 8:50 PM, Stephen Boyd <stephen.boyd@...aro.org> wrote:
> The 'blob' we pass into populate_properties() is marked as const,
> but we cast that const away when we assign the result of
> fdt_getprop_by_offset() to pp->value. Let's mark value as const
> instead, so that code can't mistakenly write to the value of the
> property that we've so far advertised as const.
>
> Unfortunately, this exposes a problem with the fdt resolver code,
> where we overwrite the value member of properties of phandles to
> update them with their final value. Add a comment for now to
> indicate where we're potentially writing over const data.
>
> You can see the problem here by loading an overlay dtb into
> the kernel via the request firmware helper method (not direct
> loading) and then passing that tree to the resolver on an arm64
> device. In this case, the firmware data is vmapped with KERNEL_PAGE_RO
> and the code crashes when attempting to write to the blob to update
> the phandle properties.

This problem exists with or without this patch, right?

> Signed-off-by: Stephen Boyd <stephen.boyd@...aro.org>
> ---
>
> I was thinking perhaps it would work to store another __be32 variant
> of the phandle in each device node, but then we still have a problem
> with properties that have phandles inside them at some offset that we
> need to update. I guess the only real solution is to deep copy the
> property in that case and then save around some info to free the
> duplicated property later on?

Couldn't we just copy the overlay and free the firmware blob in this
case? That seems easier than trying to selectively copy things. We
keep the base FDT to pass to userspace and we could need that for
overlays, but not ones we load from userspace.

Rob