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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CAKv+Gu-BOKTHb24LnemKmvCwZn0W-NOT=avY94wkkRTx2ViW=Q@mail.gmail.com>
Date:	Wed, 19 Aug 2015 11:42:02 +0200
From:	Ard Biesheuvel <ard.biesheuvel@...aro.org>
To:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Gabriel Somlo <somlo@....edu>,
	"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@...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,
	galak@...eaurora.org, linux-api@...r.kernel.org
Cc:	Leif Lindholm <leif.lindholm@...aro.org>,
	Ard Biesheuvel <ard.biesheuvel@...aro.org>
Subject: Re: [PATCH v2 0/3] SysFS driver for QEMU fw_cfg device

(missed some cc's)

On 19 August 2015 at 11:38, Ard Biesheuvel <ard.biesheuvel@...aro.org> wrote:
> From: "Gabriel L. Somlo" <somlo@....edu>
>
> Hi Gabriel,
>
>> 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?
>
>> In addition to cc-ing the people and lists indicated by get-maintainer.pl,
>> I've added a few extra lists suggested by Matt Fleming on the qemu-devel
>> list, as well as the qemu-devel list itself.
>>
>> Also cc-ing kernelnewbies, as this is my very first kenel contribution,
>> so please go easy on me for whatever silly n00b mistakes I might have still
>> missed, in spite of trying hard to do all my homework properly... :)
>>
>> The series consists of three patches:
>>
>>   1/3 - probes for the qemu fw_cfg device in locations known to work on
>>       the supported architectures, in decreasing order of "likelihood".
>>
>>       While it *may* be possible to detect the presence of fw_cfg via
>>       acpi or dtb (on x86 and arm, respectively), there's no way I know
>>       of attempting that on sun4 and ppc/mac, so I've stuck with simply
>>       probing (the fw_cfg_modes[] structure and fw_cfg_io_probe() function)
>>       in fw_cfg.c. I could use some advice on how else that could be
>>       done more elegantly, if needed.
>>
>
> Sorry, but this is really out of the question, at least on ARM, but surely on
> other architectures as well. You can't just go around and probe random memory
> addresses. Perhaps QEMU tolerates it, but on anything that resembles a real
> system, this will immediately blow up. Also, what happens if the QEMU memory
> map changes? Add more probes addresses?
>
> It is not /that/ difficult to simply wire it up to the DT and ACPI
> infrastructures, there are plenty of examples in the kernel tree how to
> accomplish that. As a bonus, it removes all the arch specific knowledge
> from your code, which means that if QEMU grows support for another DT or
> ACPI based architecture, it will just work.
>
> I am not sure how relevant sun4 and ppc/mac are for what you are trying to
> accomplish, but perhaps it would be best to focus on x86 and ARM for now
> and do it correctly. If the probing is actually needed, you can always add
> it later.
>
> --
> 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/