[llvm-dev] [lld][ELF] Add option to make .dynamic read only

[Rui Ueyama via llvm-dev]

On Fri, May 19, 2017 at 6:38 PM, Petr Hosek <phosek at chromium.org> wrote:

> On Wed, May 17, 2017 at 1:44 PM Peter Collingbourne <peter at pcc.me.uk>
> wrote:
>
>> On Wed, May 17, 2017 at 1:32 PM, Rui Ueyama via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>> On Wed, May 17, 2017 at 1:11 PM, Petr Hosek <phosek at chromium.org> wrote:
>>>
>>>> The motivation is not only memory savings but also security:
>>>> can-never-be-written is strictly better than RELRO in all cases. The
>>>> biggest win is when .dynamic is the sole reason for having a writable
>>>> segment at all. The distinction is fairly small for exploitability, but not
>>>> negligible.
>>>>
>>>
>>> I'm not even sure if it is strictly better to make .dynamic read-only by
>>> default is better than relro. It seems almost the same to me. What are
>>> attack scenario you can think of in which you can exploit only when
>>> .dynamic sections are read-only from beginning?
>>>
>> Maybe Fuchsia OS does something special for executable that contain
>>> read-only sections only?
>>>
>>
> There's one use case we have which is the vDSO. Our kernel has to be able
> to load this vDSO into every process, but we don't want to include full ELF
> loader in our kernel, so we use the read-only layout for the vDSO. Combined
> with page-aligned segments which LLD uses by default, the logic for loading
> vDSO is trivial. We're considering other use cases as well.
>

If you are writing an in-kernel ELF loader which doesn't support all
features, you can just ignore "w" bits of segments and map all segments as
read-only, can't you? It doesn't sound like you need a generic solution.


>
>>  I'd be interested in this as well, CFI relies on relro for its vtable
>> protection to work. Is the issue just the window of opportunity between
>> mapping the pages and protecting them?
>>
>
> Correct, it eliminates the short window between mapping the page and
> protecting it. There's also the memory saving; it's only a single page per
> dynamic library which isn't a lot, by if you multiply that by the number of
> processes times the number of shared libraries used by these it can become
> more significant.
>
>
>> LLD already has several command-line options that are not supported by or
>>>> are different from ld or gold, so this wouldn't be the first one (and
>>>> probably not the last). If LLD supported per-OS configuration, we would
>>>> make this default for Fuchsia and wouldn't need the new option, but since
>>>> these don't exists, it's something we would handle through the Clang driver.
>>>>
>>>
>>> Yes, we have bunch of options that are not supported by GNU linkers,
>>> particularly for LTO. So adding new options is fine as long as doing it
>>> makes sense. But the bar should be higher than implementing compatible
>>> options.
>>>
>>
> One of the design principles we're trying to follow is to make everything
> read-only, unless it has be writable. The only reason for .dynamic to be
> writable is DT_DEBUG which is something we never intend to support. FWIW in
> Fuchsia all we need is a read-only .dynamic without emitting DT_DEBUG
> altogether, but we wanted to make sure that this flag is also usable
> elsewhere hence implementing DT_DEBUG_INDIRECT which is already supported
> by musl as Jake pointed out.
>
>
>> Having no host OS-specific default options in the linker is more like a
>>> feature than a lack of a feature. We rely on compilers to give appropriate
>>> options to us. That makes the linker's behavior more predictable, and it
>>> also makes it very easy to support cross-linking.
>>>
>>
>> Note that you could avoid needing to add a new flag by defining a new
>> ELFOSABI for Fuchsia and making this behaviour conditional on it.
>>
>
> I'd rather have a flag and have our driver set it. ELFOSABI requires
> driver support which means it becomes difficult to produce Fuchsia binaries
> with compilers that don't have the right driver (e.g. we have some
> developers using a combination of GCC with LLD and this would be an issue
> for them). I'm also not sure how well is ELFOSABI supported with LTO?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170522/38658e64/attachment.html>