llvm dev - Oct 2013 - [LLVMdev] [lld] Verifying the Architecture of files read

Hi,

It is needed that lld verifies the input to the linker.

For example : a x86 ELF file can be given to lld when the target is 
x86_64. Similiarly with other flavors.

I was thinking to have a varargs function in the LinkingContext that 
would be overridden by each of the LinkingContexts to verify files after 
being read.

The reader would call the varargs function in the LinkingContext and 
raise an error if the input is not suitable with the current link mode.

Thanks

Shankar Easwaran

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the
Linux Foundation

On Fri, Oct 4, 2013 at 8:50 PM, Shankar Easwaran <shankare at
codeaurora.org>wrote:
> Hi,
>
> It is needed that lld verifies the input to the linker.
>
> For example : a x86 ELF file can be given to lld when the target is
> x86_64. Similiarly with other flavors.
>
> I was thinking to have a varargs function in the LinkingContext that would
> be overridden by each of the LinkingContexts to verify files after being
> read.
>
> The reader would call the varargs function in the LinkingContext and raise
> an error if the input is not suitable with the current link mode.
>
> Thanks
>
> Shankar Easwaran
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted
> by the Linux Foundation
>
>
Why would it need to be varargs? Also, parse can just return an error that
specifies the format is wrong.

Specifically this would be a good place to use the user data part of
ErrorOr to specify what was expected and what was received.

- Michael Spencer
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131004/bcef6970/attachment.html>

On 10/4/2013 11:16 PM, Michael Spencer wrote:
> On Fri, Oct 4, 2013 at 8:50 PM, Shankar Easwaran <shankare at
codeaurora.org>wrote:
>
>> Hi,
>>
>> It is needed that lld verifies the input to the linker.
>>
>> For example : a x86 ELF file can be given to lld when the target is
>> x86_64. Similiarly with other flavors.
>>
>> I was thinking to have a varargs function in the LinkingContext that
would
>> be overridden by each of the LinkingContexts to verify files after
being
>> read.
>>
>> The reader would call the varargs function in the LinkingContext and
raise
>> an error if the input is not suitable with the current link mode.
>>
>> Thanks
>>
>> Shankar Easwaran
>>
>> --
>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted
>> by the Linux Foundation
>>
>>
> Why would it need to be varargs?
LinkingContext for ELF would require fields from the ELF header to 
verify if the file thats being read belongs to the current target 
architecture.

I am not sure of how many fields would determine the same for Darwin and 
COFF.

This is the reason I thought it should be varargs.
> Also, parse can just return an error that
> specifies the format is wrong.
It would still need to call the LinkingContext to figure out if the 
format is associated with the target.
> Specifically this would be a good place to use the user data part of
> ErrorOr to specify what was expected and what was received.
Couldnt follow this. Can you elaborate ?

Thanks

Shankar Easwaran

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the
Linux Foundation

On Fri, Oct 04, 2013 at 10:50:02PM -0500, Shankar Easwaran
wrote:
> It is needed that lld verifies the input to the linker.
> 
> For example : a x86 ELF file can be given to lld when the target is
> x86_64. Similiarly with other flavors.
There are two different situations that need to be handled differently.
If the user specifies a path to an incompatbile file, it should create
an error. If the search for a library finds an incompatible file, it
should be skipped and a non-fatal warning might be emitted.

Joerg

On Oct 4, 2013, at 8:50 PM, Shankar Easwaran <shankare at codeaurora.org>
wrote:
> It is needed that lld verifies the input to the linker.
> 
> For example : a x86 ELF file can be given to lld when the target is x86_64.
Similiarly with other flavors.
> 
> I was thinking to have a varargs function in the LinkingContext that would
be overridden by each of the LinkingContexts to verify files after being read.
> 
> The reader would call the varargs function in the LinkingContext and raise
an error if the input is not suitable with the current link mode.
Yes.  We need a way to error out if there is an architecture mismatch.  But
there are some interesting scenarios we need to support.

* If linking with a static library, you may not know until you actually need to
load one of the members if the architecture is wrong, and it may not be an error
if the architecture is wrong, but nothing is loaded.

* It might be a warning instead of an error to link against a shared library of
the wrong architecture.  That is, the linker may need to ignore (and warn) but
continue and try to complete the link without it.

* The mach-o linker also allows you to not specify the architecture on the
command line.  Instead the linker infers the architecture by looking at the
first object file.  This is mostly used in -r mode.  So, where the check is done
to see that the arch is correct, may actually cause the architecture in the
LinkingContext to be set.

* mach-o also has “fat” files which can contain multiple architectures.  So, the
reader needs to know the arch to even try to parse.  In other words, if the
Reader is told the intended arch, the Reader could error out if the file is not
of that arch (and for mach-o the Reader would select the right slice in a fat
file).

-Nick

On 10/7/2013 3:23 PM, Nick Kledzik wrote:
> On Oct 4, 2013, at 8:50 PM, Shankar Easwaran <shankare at
codeaurora.org> wrote:
>> It is needed that lld verifies the input to the linker.
>>
>> For example : a x86 ELF file can be given to lld when the target is
x86_64. Similiarly with other flavors.
>>
>> I was thinking to have a varargs function in the LinkingContext that
would be overridden by each of the LinkingContexts to verify files after being
read.
>>
>> The reader would call the varargs function in the LinkingContext and
raise an error if the input is not suitable with the current link mode.
> Yes.  We need a way to error out if there is an architecture mismatch.  But
there are some interesting scenarios we need to support.
Ok. will create a varArg function (verifyArch ?)

I am trying to see if variadic functions would be another alternative too.
> * If linking with a static library, you may not know until you actually
need to load one of the members if the architecture is wrong, and it may not be
an error if the architecture is wrong, but nothing is loaded.
>
> * It might be a warning instead of an error to link against a shared
library of the wrong architecture.  That is, the linker may need to ignore (and
warn) but continue and try to complete the link without it.
>
> * The mach-o linker also allows you to not specify the architecture on the
command line.  Instead the linker infers the architecture by looking at the
first object file.  This is mostly used in -r mode.  So, where the check is done
to see that the arch is correct, may actually cause the architecture in the
LinkingContext to be set.
For lld, I think the flavor also would need to be inferred from the 
first object, isnt it ?
>
> * mach-o also has “fat” files which can contain multiple architectures. 
So, the reader needs to know the arch to even try to parse.  In other words, if
the Reader is told the intended arch, the Reader could error out if the file is
not of that arch (and for mach-o the Reader would select the right slice in a
fat file).
Since all of the code ends up within the parseFile function in the 
Reader, we should be able to query LinkingContext and return an actual 
error/warning on a need basis and only on valid scenarios.

Thanks

Shankar Easwaran

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the
Linux Foundation