linux-kernel - Re: [PATCH v2] platform: x86: Add ACPI driver for ChromeOS

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: <e29d6279-d7e3-8164-3f52-5017bfe79436@collabora.com>
Date:   Wed, 25 Mar 2020 22:54:59 +0100
From:   Enric Balletbo i Serra <enric.balletbo@...labora.com>
To:     Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     linux-kernel@...r.kernel.org, vbendeb@...omium.org,
        groeck@...omium.org, bleung@...omium.org, dtor@...omium.org,
        gwendal@...omium.org, andy@...radead.org,
        Collabora Kernel ML <kernel@...labora.com>,
        Ayman Bagabas <ayman.bagabas@...il.com>,
        Darren Hart <dvhart@...radead.org>,
        Dmitry Torokhov <dmitry.torokhov@...il.com>,
        Jeremy Soller <jeremy@...tem76.com>,
        Mattias Jacobsson <2pi@....nu>,
        Mauro Carvalho Chehab <mchehab+samsung@...nel.org>,
        Rajat Jain <rajatja@...gle.com>,
        Yauhen Kharuzhy <jekhor@...il.com>,
        platform-driver-x86@...r.kernel.org
Subject: Re: [PATCH v2] platform: x86: Add ACPI driver for ChromeOS

Hi Srinivas,

On 25/3/20 22:41, Srinivas Pandruvada wrote:
> Hi Enric,
> 
> On Wed, 2020-03-25 at 21:34 +0100, Enric Balletbo i Serra wrote:
>> Hi Srinivas,
>>
>> On 24/3/20 18:20, Srinivas Pandruvada wrote:
>>> On Tue, 2020-03-24 at 18:08 +0100, Enric Balletbo i Serra wrote:
>>>> Hi Greg,
>>>>
>>>> On 24/3/20 17:49, Greg Kroah-Hartman wrote:
>>>>> On Tue, Mar 24, 2020 at 05:31:10PM +0100, Enric Balletbo i
>>>>> Serra
>>>>> wrote:
>>>>>> Hi Greg,
>>>>>>
>>>>>> Many thanks for your quick answer, some comments below.
>>>>>>
>>> [...]
>>>
>>>>> Are you sure they aren't already there under
>>>>> /sys/firmware/acpi/?  I
>>>>> thought all tables and methods were exported there with no need
>>>>> to
>>>>> do
>>>>> anything special.
>>>>>
>>>>
>>>> That's the first I did when I started to forward port this patch
>>>> from
>>>> chromeos
>>>> kernel to mainline.
>>>>
>>>> On my system I get:
>>>>
>>>> /sys/firmware/acpi/tables#
>>>> APIC  DSDT  FACP  FACS  HPET  MCFG  SSDT  data  dynamic
>>>>
>>>> (data and dynamic are empty directories)
>>>>
>>>> I quickly concluded (maybe wrong) that as there is no a MLST
>>>> entry it
>>>> was not
>>>> exported, but maybe one of those already contains the info? Or,
>>>> should I expect
>>>> a MLST entry here?
>>>>
>>> If the data you are reading doesn't depend on any runtime variable
>>> in
>>> ACPI tables then you can read from firmware tables as is.
>>>
>>> You can download acpica tools and run your method on acpi dump
>>> using
>>> acpiexec tool. Once you can take dump, you can run on any Linux
>>> system.
>>>
>>> If you can get what you need from running on the dump, then you can
>>> do
>>> by directly reading from /sys/firmware/acpi/tables/ from user space
>>> without kernel change. Sometimes it is enough as lots of config
>>> data
>>> tend to be static.
>>>
>>
>> As I said I'm not an ACPI expert, so thanks in advance for your help.
>>
>> I am trying to look if I can get from userspace the value of the HWID
>> entry
>> exported from the driver.
>>
>> $ cat /sys/devices/platform/chromeos_acpi/HWID
>> SAMUS E25-G7R-W35
>>
>> Using acpiexec I get the element list of the MLST method, but I don't
>> know how
>> to get the HWID value.
>>
>> - evaluate crhw.mlst
>> Evaluating \CRHW.MLST
>> Evaluation of \CRHW.MLST returned object 0x55f17a7aed60, external
>> buffer length 158
>>   [Package] Contains 10 Elements:
>>     [String] Length 04 = "CHSW"
>>     [String] Length 04 = "FWID"
>>     [String] Length 04 = "HWID"
>>     [String] Length 04 = "FRID"
>>     [String] Length 04 = "BINF"
>>     [String] Length 04 = "GPIO"
>>     [String] Length 04 = "VBNV"
>>     [String] Length 04 = "VDAT"
>>     [String] Length 04 = "FMAP"
>>     [String] Length 04 = "MECK"
>>
>> Any clue?
>>
> So I guess your  mlst method gives list of methods you can call.
> So here your can directly evaluate
> 
> - evaluate crhw.HWID
> 

Right, I tried, but that doesn't gives the result I want, for example:

Evaluating \CRHW.HWID
0x1 Outstanding allocations after evaluation of \CRHW.HWID
Evaluation of \CRHW.HWID returned object 0x55b9e373fd60, external buffer length 38
  [Package] Contains 1 Elements:
    [String] Length 00 = ""


I found that the VBTx are addresses setup in the following file.

src/vendorcode/google/chromeos/acpi/gnvs.asl:

VBT0,   32,     // 0x000 - Boot Reason
VBT1,   32,     // 0x004 - Active Main Firmware
VBT2,   32,     // 0x008 - Active EC Firmware
VBT3,   16,     // 0x00c - CHSW
VBT4, 2048,     // 0x00e - HWID
VBT5,  512,     // 0x10e - FWID
VBT6,  512,     // 0x14e - FRID
VBT7,   32,     // 0x18e - active main firmware type
VBT8,   32,     // 0x192 - Recovery Reason
VBT9,   32,     // 0x196 - FMAP base address
CHVD, 24576,    // 0x19a - VDAT space filled by verified boot
VBTA,   32,     // 0xd9a - pointer to smbios FWID
MEHH,  256,     // 0xd9e - Management Engine Hash
RMOB,   32,     // 0xdbe - RAM oops base address
RMOL,   32,     // 0xdc2 - RAM oops length
ROVP,   32,     // 0xdc6 - pointer to RO_VPD
ROVL,   32,     // 0xdca - size of RO_VPD
RWVP,   32,     // 0xdce - pointer to RW_VPD
RWVL,   32,     // 0xdd2 - size of RW_VPD
                // 0xdd6

Can I assume that the info I want is only accessible in runtime and is not
exported via the static tables?

Thanks,
 Enric


> 
> Thanks,
> Srinivas
> 
> 
> 
>> Thanks in advance,
>> Enric
>>
>>
>>> Thanks,
>>> Srinivas
>>>
>>>
>>>
>>>
>>>
>>>
>>>>> What makes these attributes "special" from any other ACPI
>>>>> method?
>>>>>
>>>>
>>>> I can't answer this question right now. I need to investigate
>>>> more I
>>>> guess ;-)
>>>>
>>>> Thanks again for your answer,
>>>> Enric
>>>>
>>>>>>>> +static int __init chromeos_acpi_init(void)
>>>>>>>> +{
>>>>>>>> +	int ret;
>>>>>>>> +
>>>>>>>> +	chromeos_acpi.pdev =
>>>>>>>> platform_device_register_simple("chromeos_acpi",
>>>>>>>> +						PLATFORM_DEVID_
>>>>>>>> NONE, NULL, 0);
>>>>>>>> +	if (IS_ERR(chromeos_acpi.pdev)) {
>>>>>>>> +		pr_err("unable to register chromeos_acpi
>>>>>>>> platform device\n");
>>>>>>>> +		return PTR_ERR(chromeos_acpi.pdev);
>>>>>>>> +	}
>>>>>>>
>>>>>>> Only use platform devices and drivers for things that are
>>>>>>> actually
>>>>>>> platform devices and drivers.  That's not what this is, it
>>>>>>> is
>>>>>>> an ACPI
>>>>>>> device and driver.  Don't abuse the platform interface
>>>>>>> please.
>>>>>>>
>>>>>>
>>>>>> Ok. The purpose was to not break ChromeOS userspace since is
>>>>>> looking for the
>>>>>> attributes inside /sys/devices/platform/chromeos_acpi. Not a
>>>>>> good
>>>>>> reason, I
>>>>>> know, and I assume we will need to change userspace instead,
>>>>>> and
>>>>>> convert this to
>>>>>> a ACPI device and driver only, right?
>>>>>
>>>>> How can any userspace be looking for anything that hasn't been
>>>>> submitted
>>>>> before?  That's nothing to worry about, we don't have to
>>>>> support
>>>>> things
>>>>> like that :)
>>>>>
>>>>>> I'll investigate the different places in userspace where this
>>>>>> is
>>>>>> used and see
>>>>>> how difficult it is to do the changes.
>>>>>
>>>>> Look at /sys/firmware/acpi/ first please.
>>>>>
>>>>> thanks,
>>>>>
>>>>> greg k-h
>>>>>
>