linux-kernel - Re: ERROR: INT DW_ATE_unsigned

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:   Sat, 6 Feb 2021 11:17:07 -0800
From:   Yonghong Song <yhs@...com>
To:     <sedat.dilek@...il.com>
CC:     Mark Wieelard <mark@...mp.org>,
        Masahiro Yamada <masahiroy@...nel.org>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        Arnaldo Carvalho de Melo <arnaldo.melo@...il.com>,
        <dwarves@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        <bpf@...r.kernel.org>, Jiri Olsa <jolsa@...nel.org>,
        Jan Engelhardt <jengelh@...i.de>,
        Domenico Andreoli <cavok@...ian.org>,
        Matthias Schwarzott <zzam@...too.org>,
        Andrii Nakryiko <andriin@...com>,
        Paul Moore <paul@...l-moore.com>,
        Ondrej Mosnacek <omosnace@...hat.com>,
        Daniel P. Berrangé <berrange@...hat.com>,
        Tom Stellard <tstellar@...hat.com>
Subject: Re: ERROR: INT DW_ATE_unsigned_1 Error emitting BTF type



On 2/6/21 10:10 AM, Sedat Dilek wrote:
> On Sat, Feb 6, 2021 at 6:53 PM Yonghong Song <yhs@...com> wrote:
>>
>>
>>
>> On 2/6/21 8:24 AM, Mark Wieelard wrote:
>>> Hi,
>>>
>>> On Sat, Feb 06, 2021 at 12:26:44AM -0800, Yonghong Song wrote:
>>>> With the above vmlinux, the issue appears to be handling
>>>> DW_ATE_signed_1, DW_ATE_unsigned_{1,24,40}.
>>>>
>>>> The following patch should fix the issue:
>>>
>>> That doesn't really make sense to me. Why is the compiler emitting a
>>> DW_TAG_base_type that needs to be interpreted according to the
>>> DW_AT_name attribute?
>>>
>>> If the issue is that the size of the base type cannot be expressed in
>>> bytes then the DWARF spec provides the following option:
>>>
>>>       If the value of an object of the given type does not fully occupy
>>>       the storage described by a byte size attribute, the base type
>>>       entry may also have a DW_AT_bit_size and a DW_AT_data_bit_offset
>>>       attribute, both of whose values are integer constant values (see
>>>       Section 2.19 on page 55). The bit size attribute describes the
>>>       actual size in bits used to represent values of the given
>>>       type. The data bit offset attribute is the offset in bits from the
>>>       beginning of the containing storage to the beginning of the
>>>       value. Bits that are part of the offset are padding.  If this
>>>       attribute is omitted a default data bit offset of zero is assumed.
>>>
>>> Would it be possible to use that encoding of those special types?  If
>>
>> I agree with you. I do not like comparing me as well. Unfortunately,
>> there is no enough information in dwarf to find out actual information.
>> The following is the dwarf dump with vmlinux (Sedat provided) for
>> DW_ATE_unsigned_1.
>>
>> 0x000e97e9:   DW_TAG_base_type
>>                   DW_AT_name      ("DW_ATE_unsigned_1")
>>                   DW_AT_encoding  (DW_ATE_unsigned)
>>                   DW_AT_byte_size (0x00)
>>
>> There is no DW_AT_bit_size and DW_AT_bit_offset for base type.
>> AFAIK, these two attributes typically appear in struct/union members
>> together with DW_AT_byte_size.
>>
>> Maybe compilers (clang in this case) can emit DW_AT_bit_size = 1
>> and DW_AT_bit_offset = 0/7 (depending on big/little endian) and
>> this case, we just test and get DW_AT_bit_size and it should work.
>>
>> But I think BTF does not need this (DW_ATE_unsigned_1) for now.
>> I checked dwarf dump and it is mostly used for some arith operation
>> encoded in dump (in this case, e.g., shift by 1 bit)
>>
>> 0x000015cf:   DW_TAG_base_type
>>                   DW_AT_name      ("DW_ATE_unsigned_1")
>>                   DW_AT_encoding  (DW_ATE_unsigned)
>>                   DW_AT_byte_size (0x00)
>>
>> 0x00010ed9:         DW_TAG_formal_parameter
>>                         DW_AT_location    (DW_OP_lit0, DW_OP_not,
>> DW_OP_convert (0x000015cf) "DW_ATE_unsigned_1", DW_OP_convert
>> (0x000015d4) "DW_ATE_unsigned_8", DW_OP_stack_value)
>>                         DW_AT_abstract_origin     (0x00013984 "branch")
>>
>> Look at clang frontend, only the following types are encoded with
>> unsigned dwarf type.
>>
>>     case BuiltinType::UShort:
>>     case BuiltinType::UInt:
>>     case BuiltinType::UInt128:
>>     case BuiltinType::ULong:
>>     case BuiltinType::WChar_U:
>>     case BuiltinType::ULongLong:
>>       Encoding = llvm::dwarf::DW_ATE_unsigned;
>>       break;
>>
>>
>>> not, can we try to come up with some extension that doesn't require
>>> consumers to match magic names?
>>>
> 
> You want me to upload mlx5_core.ko?

I just sent out a patch. You are cc'ed. I also attached in this email.
Yes, it would be great if you can upload mlx5_core.ko so I can
double check with this DW_ATE_unsigned_160 which is really usual.

> 
> When looking with llvm-dwarf for DW_ATE_unsigned_160:
> 
> 0x00d65616:   DW_TAG_base_type
>                 DW_AT_name      ("DW_ATE_unsigned_160")
>                 DW_AT_encoding  (DW_ATE_unsigned)
>                 DW_AT_byte_size (0x14)
> 
> If you need further information, please let me know.
> 
> Thanks.
> 
> - Sedat -
> 

View attachment "0001-btf_encoder-sanitize-non-regular-int-base-type.patch" of type "text/plain" (5139 bytes)