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] [day] [month] [year] [list]
Message-ID: <2595d3db-4149-5764-c265-62af273fb3e5@cn.fujitsu.com>
Date:   Fri, 27 Sep 2019 10:09:05 +0800
From:   Cao jin <caoj.fnst@...fujitsu.com>
To:     <hpa@...or.com>, Ingo Molnar <mingo@...nel.org>
CC:     <x86@...nel.org>, <linux-kernel@...r.kernel.org>,
        <linux-doc@...r.kernel.org>, <tglx@...utronix.de>,
        <mingo@...hat.com>, <bp@...en8.de>, <corbet@....net>
Subject: Re: [RFC PATCH] x86/doc/boot_protocol: Correct the description of
 "reloc"

On 9/27/19 3:18 AM, hpa@...or.com wrote:
> On September 26, 2019 1:20:02 AM PDT, Cao jin <caoj.fnst@...fujitsu.com> wrote:
>> On 9/26/19 3:58 PM, hpa@...or.com wrote:
>>> On September 26, 2019 12:55:51 AM PDT, Cao jin
>> <caoj.fnst@...fujitsu.com> wrote:
>>>> On 9/26/19 2:01 PM, Ingo Molnar wrote:
>>>>> * Cao jin <caoj.fnst@...fujitsu.com> wrote:
>>>>>
>>>>>> The fields marked with (reloc) actually are not dedicated for
>>>> writing,
>>>>>> but communicating info for relocatable kernel with boot loaders.
>> For
>>>>>> example:
>>>>>>
>>>>>>     ============    ============
>>>>>>     Field name:     pref_address
>>>>>>     Type:           read (reloc)
>>>>>>     Offset/size:    0x258/8
>>>>>>     Protocol:       2.10+
>>>>>>     ============    ============
>>>>>>
>>>>>>     ============    ========================
>>>>>>     Field name:     code32_start
>>>>>>     Type:           modify (optional, reloc)
>>>>>>     Offset/size:    0x214/4
>>>>>>     Protocol:       2.00+
>>>>>>     ============    ========================
>>>>>>
>>>>>> Signed-off-by: Cao jin <caoj.fnst@...fujitsu.com>
>>>>>> ---
>>>>>> Unless I have incorrect non-native understanding for "fill in", I
>>>> think
>>>>>> this is inaccurate.
>>>>>>
>>>>>>  Documentation/x86/boot.rst | 2 +-
>>>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/Documentation/x86/boot.rst
>> b/Documentation/x86/boot.rst
>>>>>> index 08a2f100c0e6..a611bf04492d 100644
>>>>>> --- a/Documentation/x86/boot.rst
>>>>>> +++ b/Documentation/x86/boot.rst
>>>>>> @@ -243,7 +243,7 @@ bootloader ("modify").
>>>>>>  
>>>>>>  All general purpose boot loaders should write the fields marked
>>>>>>  (obligatory).  Boot loaders who want to load the kernel at a
>>>>>> -nonstandard address should fill in the fields marked (reloc);
>> other
>>>>>> +nonstandard address should consult with the fields marked
>> (reloc);
>>>> other
>>>>>>  boot loaders can ignore those fields.
>>>>>>  
>>>>>>  The byte order of all fields is littleendian (this is x86, after
>>>> all.)
>>>>>
>>>>> Well, this documentation is written from the point of view of a 
>>>>> *bootloader*, not the kernel. So the 'fill in' says that the
>>>> bootloader 
>>>>> should write those fields - which is correct, right?
>>>>>
>>>>
>>>> Take pref_address or relocatable_kernel for example, they have type:
>>>> read (reloc), does boot loader need to write them? I don't see grub
>>>> does
>>>> this at least.
>>>
>>> Read means the boot later reads them.
>>>
>>
>> Sorry I don't know what is going wrong in my mind. For me, if
>> pref_address has "read (reloc)", base on the current document, it means
>> boot loader will read it and also write it, which is conflicting. And
>> the purpose of pref_address should just inform boot loader that kernel
>> whats itself to be loaded at certain address, it don't want to be
>> written.
> 
> read (reloc) means it is information for the boot loader to read, but that it can ignore it completely if it does not want to relocate the kernel.
> 

so, "read (reloc)" also means boot loader can't write it, right?

Please bear my verbiage, see protocol explanation for "(reloc)":

"Boot loaders who want to load the kernel at a nonstandard address
should fill in the fields marked (reloc);"

Doesn't the explanation means: if boot loaders want to relocate the
kernel, they should write pref_address?

And while pref_address actually just provide a suggestion to boot
loader, loader could take it or not as you said, but won't write it.
That is why I choose the word "consult with" instead of "fill in".
-- 
Sincerely,
Cao jin


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ