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]

Date:	Wed, 19 Aug 2015 11:38:29 +0200
From:	Ard Biesheuvel <ard.biesheuvel@...aro.org>
To:	linux-kernel@...r.kernel.org, somlo@....edu
Cc:	leif.lindholm@...aro.org,
	Ard Biesheuvel <ard.biesheuvel@...aro.org>
Subject: Re: [PATCH v2 0/3] SysFS driver for QEMU fw_cfg device

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/