From: Blibbet <blibbet@gmail.com>
To: chipsec@lists.01.org
Subject: Re: Debian packaging and D-I integration
Date: Mon, 27 Jul 2015 10:47:25 -0700 [thread overview]
Message-ID: <55B66EAD.7070902@gmail.com> (raw)
In-Reply-To: <F2C8915217E2664AB33302D7A9ED9C0A22D5B9A4@hasmsx108.ger.corp.intel.com>
[-- Attachment #1: Type: text/plain, Size: 2480 bytes --]
On 07/27/2015 10:14 AM, Loucaides, John wrote:
> I think it's a great idea to play with packaging, but as you
mentioned, I do have some
> concerns about the driver. Your idea to play with this without
submitting to a real
> repository seems good. [...]
Thanks for input. I'm a newbie at Debian packaging, so I expect you'll
have plenty of time to create more concise warning text. :-)
I'm getting start with private packaging. I'll file an Intent-To-Package
bug against Debian shortly.
Changes to D-I (Debian Installer) is a much larger effort, and would be
later. I have no idea if D-I team would have an interest in a patch with
this kind of feature yet.
Also, while on this thread, I received a few answers to my Debian
packaging questions:
> I don't understand how to address
> packaging of drivers that do post-boot Linux module loading. From what
> I gather, this ability would likely be disabled on more secure systems
> (where CHIPSEC might want to be used).
AFAIK the only way to load modules after the next boot following package
installation is to add it as part of the packages' installed init
scripts. Using init to manage any CHIPSEC binaries that need to have
things happen after they exit (i.e., unloading the kernel driver) might
be a good idea.
> perhaps the
> CHIPSEC driver package should display the contents of CHIPSEC's
> warning.txt and let the use agree to this security risk, before
> installing? If so, I need to find out how to do that in a Debian
> package.
The `debconf` program can handle cases like this. It's normally used for
install-time conditional package configuration (it's the thing that asks
questions during the d-i process: the keyboard configuration, static or
dynamic network addressing, etc. all are instances of debconf
configuring a specific package.)
Joey Hess' debconf tutorial is here:
http://www.fifi.org/doc/debconf-doc/tutorial.html
> Since CHIPSEC will only work on Intel x86/x64 systems, and not
> AMD-based
> AMD64 systems, installation has to check CPU and only install on
> proper
> systems. I'm unclear how to do this check in a Debian package.
Debian calls all the consumer-grade 64-bit arches `amd64` whether the
vendor is Intel or AMD; ia64 is the name for Itanium-based Intel 64-bit
chips. If CHIPSEC doesn't work on ia64 then it's a simple matter of not
providing a package for that arch, since Debian keeps separate archives
for each arch.
next prev parent reply other threads:[~2015-07-27 17:47 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-22 17:55 Debian packaging and D-I integration Blibbet
2015-07-27 17:14 ` Loucaides, John
2015-07-27 17:42 ` Arrigo Triulzi
2015-07-27 17:47 ` Blibbet [this message]
2015-07-27 17:54 ` Loucaides, John
2015-07-27 18:46 ` Blibbet
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55B66EAD.7070902@gmail.com \
--to=blibbet@gmail.com \
--cc=chipsec@lists.01.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox