linux-kernel - Re: [RFC PATCH 10/10] acpi: add support for loading SSDTs via configfs

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: <CAE1zotKa+t5cxznWfPyQ599k9ZB=akOuEDZusWcJgzux8wqp5A@mail.gmail.com>
Date:	Wed, 6 Apr 2016 21:46:51 +0300
From:	Octavian Purdila <octavian.purdila@...el.com>
To:	"Zheng, Lv" <lv.zheng@...el.com>
Cc:	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Len Brown <lenb@...nel.org>,
	Matt Fleming <matt@...eblueprint.co.uk>,
	Mark Brown <broonie@...nel.org>,
	Wolfram Sang <wsa@...-dreams.de>,
	Joel Becker <jlbec@...lplan.org>,
	Christoph Hellwig <hch@....de>,
	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
	"linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
	"linux-i2c@...r.kernel.org" <linux-i2c@...r.kernel.org>,
	"linux-spi@...r.kernel.org" <linux-spi@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Tirdea, Irina" <irina.tirdea@...el.com>
Subject: Re: [RFC PATCH 10/10] acpi: add support for loading SSDTs via configfs

On Wed, Apr 6, 2016 at 9:05 AM, Zheng, Lv <lv.zheng@...el.com> wrote:

>> It is hard to create new kernel objects from sysfs. You need to resort
>> to hacks like using new_table sysfs entries which does not map to a
>> kernel object. Writes larger then PAGE_SIZE are impossible to handle
>> with multiple open files because you have no open callback to create a
>> file context. It is also not possible to do any clean-up because there
>> is no close callback and if something goes wrong for example when
>> trying to install the table you will leak the allocated memory.
>>
>> configfs was designed for the specific purpose of creating kernel
>> objects from userspace and addresses all of the limitations above (and
>> some more).
>>
>> Initially I started to implement this functionality via sysfs but I
>> run into the issues mentioned above and decided to use configfs.
> [Lv Zheng]
> I can sense different difficulties from your descriptions.
> Let me break it down into details.
>
> We already have acpi_table_handler working there for creating new ACPI table entries for us.
> Based on this facility, let's think about the following solution:
> 1. sysfs presenting change
> We can change the table file to a table directory whose name is in the following format:
> TableSignature-OemId-OemTableId
> Then we can get rid of the annoying numbered table name suffix first.
> The numbered table name suffix cannot be kept consistent to reflect the real index if we allow tables to be dynamically loaded/unloaded.
>
> This is the first design difficulty we need to solve.
>
> 2. acpi_table_handler change
> Now we can append 2 new events to acpi_table_handler - ACPI_TABLE_INSTALL/ACPI_TABLE_UNINSTALL.
> With which, the sysfs entries can be created/deleted when the table is added to/removed from the global table list.
> And this should be the working mechanism for us
> So we actually don't have the trouble to deal with the new kernel object creation/deletion from sysfs.
>
> I agree the dynamic kernel object creation/deletion need special care.
> But this actually is what a kernel engineer should do because this kind of things happen here and there throughout the kernel.
> We should have already been used to that.
>
> This is the second engineering difficulty we need to face.
>
> 3. load/unload commanding
> Now we need a character device in sysfs to handle load/unload command.
> Well, there are many such kind of files in sysfs, for example, device nodes.
> So this is not a non-achievable task, but just a difficult engineering task.
> The system engineers need to be skillful enough to implement this.
> Like the dynamic kernel object handling, we should have already been used to this.
>
>
> If you still think this is difficult, the alternative choice is to use acpidbg char device's ioctl interface.
> That could simplifies this task.
> And since the ioctl interface is required by ACPICA disassembler, the work on that will be inherited by the disassembler porting.
>

Why can't the dissembler access the tables through the existing sysfs interface?

> This is the last engineering difficulty we need to face.
>
> So why can't these solutions work for us?
>

It can be done, but it is not the right way to do it, IMO.