linux-kernel - Re: [PATCH v2 0/3] SysFS driver for QEMU fw

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 24 Aug 2015 09:56:29 +0200
From:	Ard Biesheuvel <ard.biesheuvel@...aro.org>
To:	"Gabriel L. Somlo" <somlo@....edu>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Richard W.M. Jones" <rjones@...hat.com>,
	Jordan Justen <jordan.l.justen@...el.com>,
	"x86@...nel.org" <x86@...nel.org>,
	QEMU Developers <qemu-devel@...gnu.org>,
	Gleb Natapov <gleb@...udius-systems.com>,
	Matt Fleming <matt.fleming@...el.com>,
	kernelnewbies@...nelnewbies.org, Gerd Hoffmann <kraxel@...hat.com>,
	Paolo Bonzini <pbonzini@...hat.com>,
	Laszlo Ersek <lersek@...hat.com>,
	"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
	ralf@...ux-mips.org, zajec5@...il.com, paul@...an.com,
	Kumar Gala <galak@...eaurora.org>, linux-api@...r.kernel.org,
	Leif Lindholm <leif.lindholm@...aro.org>
Subject: Re: [PATCH v2 0/3] SysFS driver for QEMU fw_cfg device

On 21 August 2015 at 05:47, Gabriel L. Somlo <somlo@....edu> wrote:
> On Thu, Aug 20, 2015 at 07:21:48AM +0200, Ard Biesheuvel wrote:
>> On 19 August 2015 at 22:49, Gabriel L. Somlo <somlo@....edu> wrote:
>> >> > From: "Gabriel L. Somlo" <somlo@....edu>
>> >> >> Several different architectures supported by QEMU are set up with a
>> >> >> "firmware configuration" (fw_cfg) device, used to pass configuration
>> >> >> "blobs" into the guest by the host running QEMU.
>> >> >>
>> >> >> Historically, these config blobs were mostly of interest to the guest
>> >> >> BIOS, but since QEMU v2.4 it is possible to insert arbitrary blobs via
>> >> >> the command line, which makes them potentially interesting to userspace
>> >> >> (e.g. for passing early boot environment variables, etc.).
>> >> >>
>> >> >
>> >> > Does 'potentially interesting' mean you have a use case? Could you elaborate?
>> >
>> > My personal one would be something like:
>> >
>> > cat > guestinfo.txt << EOT
>> >   KEY1="val1"
>> >   KEY2="val2"
>> >   ...
>> > EOT
>> >
>> > qemu-system-x86_64 ... -fw-cfg name="opt/guestinfo",file=./guestinfo.txt ...
>> >
>> > Then, from inside the guest:
>> >
>> >   . /sys/firmware/qemu_fw_cfg/by_name/opt/guestinfo/raw
>> >
>> >   do_something_with $KEY1 $KEY2
>> >   ...
>> >
>> > But I'm thinking this is only one of the many positive things one
>> > could do with the ability to access random host-supplied blobs from
>> > guest userspace :)
>> >
>>
>> 'random host-supplied blobs' sounds awfully like files in a file
>> system to me, and that is already supported by QEMU and works with any
>> guest OS unmodified. If you are in control of the command line, surely
>> you can add a -drive xxx,fat:path/to/blobs -device xxx pair that
>> simply turns up as a volume.
>
> That did come up, here's the start of original thread on the qemu mailing
> list from a while back:
>
> https://lists.gnu.org/archive/html/qemu-devel/2015-02/msg00371.html
>
> To recap, the main advantages to transfering data this way are:
>
>         1. Asynchronous
>
>            The host can simply pass data via the qemu command line, and
>            not have to care if/when the guest is ready to accept the
>            data (i.e. has made it far enough to e.g. start a guest agent)
>

How does that not apply to a file system?

>         2. Out-of-band
>
>            I don't have to take over a user-visible element such as a
>            disk drive. Same reason VSOCK (or VMWare VMCI for that matter)
>            exist and are NOT actual Ethernet/TCP-IP network interfaces :)
>

OK that makes sense. Note that I am not the one you need to convince
that this is a good idea, but I would still like to understand better
why your use case requires this. Could you explain?

-- 
Ard.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/