enable CONFIG_INTEL_TXT
by Eric Paris
Long ago we were ask to enable CONFIG_INTEL_TXT in the fedora kernels by
a large user, the US National Security Agency:
http://lists.fedoraproject.org/pipermail/kernel/2009-October/002228.html
At the time the objection to this configuration option was that the
technology was all predicated on a closed source binary blob signed by
Intel. In private discussions it was learned that there was no chance
that the module would ever be open sourced and we learned that hardware
is not capable of recognizing signatures of a module from other vendors
(aka Fedora can't sign our own version.) However, in light of a recent
public statement from IBM:
http://lists.fedoraproject.org/pipermail/devel/2010-March/133089.html
We see that at least one hardware vendor has been listening to our
objections to closed source software and has agreed to re-architect how
they implement their systems so that our users will not need to download
and install any closed source proprietary software. They agreed to make
any changes necessary to their BIOS (UEFI) to support this technology
without the need for the separate closed source proprietary Intel signed
blob. Red Hat has ask other hardware vendors to follow the admirable
lead set by IBM if they have any interest in being supported by the open
source community.
At this point we know that we have hardware vendors, software vendors,
and users all asking for the enablement of this technology. So the
question become why should we enable CONFIG_INTEL_TXT and what do we
get? What do we lose?
By itself enabling TXT gets us nothing except a small chuck of dead code
in the kernel. But it allows us and our customers to build new
solutions with new security goals in mind which are not possible today.
This config option allows a user to download new (open source) software
(tboot) along with other third party software to verify the correctness
of the BOOTED system. This allows us to build future solutions such as
utilizing the TPM chip in many laptops to harden the disk encryption
key. It can be used as root of trust for the verification of the
software originally loaded on a machine before it is allowed network
access (aka machines with a rootkit couldn't get on the network.) The
technology can also be extended to provide usefulness to system
integrity checkers like aide or IMA for tamper proof software integrity
logging. These are all things which are impossible to do with today's
kernels.
We don't really lose anything except a bit of code in the kernel.
Unless the user specifically installs tboot the kernel code will sit
dormant. It has no implications on AMD processors. If the user does
install tboot and their hardware supports this technology (like this
future generation of IBM system X products mentioned above) they will
get a root of trust which can be used to build other solutions. Some of
those potential solutions will hopefully be available someday in Fedora
if a user wishes to activate them (and we can overcome the management
burden they will seemingly place upon the user), but we cannot get there
without starting here.
This is the beginning. It is the first step to allow users to use other
open source software which will give them a root of trust. But remember
the config options does nothing unless a user takes those very clear
active steps.
Are there any objections to enabling CONFIG_INTEL_TXT on x86_64?
-Eric
14 years
ppc32 selinux mprotect diff.
by Dave Jones
We've carried this diff in Fedora for a few years now..
--- linux-2.6.26.noarch/security/selinux/hooks.c~ 2008-09-25 14:11:17.000000000 -0400
+++ linux-2.6.26.noarch/security/selinux/hooks.c 2008-09-25 14:12:17.000000000 -0400
@@ -3018,7 +3018,6 @@ static int file_map_prot_check(struct fi
const struct cred *cred = current_cred();
int rc = 0;
-#ifndef CONFIG_PPC32
if ((prot & PROT_EXEC) && (!file || (!shared && (prot & PROT_WRITE)))) {
/*
* We are making executable an anonymous mapping or a
@@ -3029,7 +3028,6 @@ static int file_map_prot_check(struct fi
if (rc)
goto error;
}
-#endif
if (file) {
/* read access is always possible with a mapping */
@@ -3024,7 +3022,6 @@ static int selinux_file_mprotect(struct
if (selinux_checkreqprot)
prot = reqprot;
-#ifndef CONFIG_PPC32
if ((prot & PROT_EXEC) && !(vma->vm_flags & VM_EXEC)) {
rc = 0;
if (vma->vm_start >= vma->vm_mm->start_brk &&
@@ -3049,7 +3046,6 @@ static int selinux_file_mprotect(struct
if (rc)
return rc;
}
-#endif
return file_map_prot_check(vma->vm_file, prot, vma->vm_flags&VM_SHARED);
}
This needs a fixed toolchain, and a userspace rebuild to work.
For these reasons, it's had difficulty getting upstream.
Fedora has a new enough toolchain, and has been rebuilt, so we don't need
the ifdefs. Other distros don't/haven't, and this patch would break them
if pushed upstream.
Could we do something like the (untested) diff below instead,
which might be more palatable to upstream, allowing us to stop
carrying it ?
Dave
diff --git a/security/selinux/Kconfig b/security/selinux/Kconfig
index bca1b74..83a9675 100644
--- a/security/selinux/Kconfig
+++ b/security/selinux/Kconfig
@@ -131,3 +131,10 @@ config SECURITY_SELINUX_POLICYDB_VERSION_MAX_VALUE
installed under /etc/selinux/$SELINUXTYPE/policy, where
SELINUXTYPE is defined in your /etc/selinux/config.
+config SELINUX_NEW_ENOUGH_TOOLCHAIN
+ bool "SELinux mprotect checks"
+ default n if PPC32
+ help
+ This option requires a modern toolchain (FIXME: Version?)
+ and a userspace rebuild to work.
+
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 9a2ee84..e805df7 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -3009,7 +3009,7 @@ static int file_map_prot_check(struct file *file, unsigned long prot, int shared
const struct cred *cred = current_cred();
int rc = 0;
-#ifndef CONFIG_PPC32
+#ifdef CONFIG_SELINUX_NEW_ENOUGH_TOOLCHAIN
if ((prot & PROT_EXEC) && (!file || (!shared && (prot & PROT_WRITE)))) {
/*
* We are making executable an anonymous mapping or a
@@ -3081,7 +3081,7 @@ static int selinux_file_mprotect(struct vm_area_struct *vma,
if (selinux_checkreqprot)
prot = reqprot;
-#ifndef CONFIG_PPC32
+#ifdef CONFIG_SELINUX_NEW_ENOUGH_TOOLCHAIN
if ((prot & PROT_EXEC) && !(vma->vm_flags & VM_EXEC)) {
int rc = 0;
if (vma->vm_start >= vma->vm_mm->start_brk &&
14 years
[PATCH F-13 2.6.33 1/2] iwlwifi: reset card during probe
by Stanislaw Gruszka
To ensure that card is in a sane state during probe we add a reset call.
This change was prompted by users of kdump who was not able to bring up the
wireless driver in the kdump kernel. The problem here was that the primary
kernel, which is not running at the time, left the wireless card up and
running. When the kdump kernel starts it is thus possible to immediately
receive interrupts from firmware after registering interrupt, but without
being ready to deal with interrupts from firmware yet.
Reported-by: Stanislaw Gruszka <sgruszka(a)redhat.com>
Signed-off-by: Reinette Chatre <reinette.chatre(a)intel.com>
Signed-off-by: Stanislaw Gruszka <sgruszka(a)redhat.com>
---
drivers/net/wireless/iwlwifi/iwl-agn.c | 8 ++++++++
drivers/net/wireless/iwlwifi/iwl3945-base.c | 7 +++++++
2 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn.c b/drivers/net/wireless/iwlwifi/iwl-agn.c
index 1c9866d..33a7803 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn.c
@@ -3365,6 +3365,14 @@ static int iwl_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
*/
spin_lock_init(&priv->reg_lock);
spin_lock_init(&priv->lock);
+
+ /*
+ * stop and reset the on-board processor just in case it is in a
+ * strange state ... like being left stranded by a primary kernel
+ * and this is now the kdump kernel trying to start up
+ */
+ iwl_write32(priv, CSR_RESET, CSR_RESET_REG_FLAG_NEVO_RESET);
+
iwl_hw_detect(priv);
IWL_INFO(priv, "Detected Intel Wireless WiFi Link %s REV=0x%X\n",
priv->cfg->name, priv->hw_rev);
diff --git a/drivers/net/wireless/iwlwifi/iwl3945-base.c b/drivers/net/wireless/iwlwifi/iwl3945-base.c
index f8e4e4b..f0c428e 100644
--- a/drivers/net/wireless/iwlwifi/iwl3945-base.c
+++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c
@@ -4022,6 +4022,13 @@ static int iwl3945_pci_probe(struct pci_dev *pdev, const struct pci_device_id *e
spin_lock_init(&priv->reg_lock);
spin_lock_init(&priv->lock);
+ /*
+ * stop and reset the on-board processor just in case it is in a
+ * strange state ... like being left stranded by a primary kernel
+ * and this is now the kdump kernel trying to start up
+ */
+ iwl_write32(priv, CSR_RESET, CSR_RESET_REG_FLAG_NEVO_RESET);
+
/***********************
* 4. Read EEPROM
* ********************/
--
1.6.2.5
14 years, 1 month
[PATCH 1/3] iwlwifi: fix nfreed--
by Stanislaw Gruszka
During backporting of a120e912eb51e347f36c71b60a1d13af74d30e83
("iwlwifi: sanity check before counting number of tfds can be free ")
we forget one hunk, what make lot of messages "free more than
tfds_in_queue" mess up dmesg.
Signed-off-by: Stanislaw Gruszka <sgruszka(a)redhat.com>
---
drivers/net/wireless/iwlwifi/iwl-tx.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-tx.c b/drivers/net/wireless/iwlwifi/iwl-tx.c
index f449f06..cf5ac00 100644
--- a/drivers/net/wireless/iwlwifi/iwl-tx.c
+++ b/drivers/net/wireless/iwlwifi/iwl-tx.c
@@ -1096,7 +1096,6 @@ int iwl_tx_queue_reclaim(struct iwl_priv *priv, int txq_id, int index)
priv->cfg->ops->lib->txq_inval_byte_cnt_tbl(priv, txq);
priv->cfg->ops->lib->txq_free_tfd(priv, txq);
- nfreed++;
}
return nfreed;
}
--
1.6.2.5
14 years, 1 month
[PATCH] iwlwifi: fix nfreed--
by y＠redhat.com
During backporting of a120e912eb51e347f36c71b60a1d13af74d30e83
("iwlwifi: sanity check before counting number of tfds can be free ")
we forget one hunk, what make lot of messages "free more than
tfds_in_queue" mess up dmesg.
Signed-off-by: Stanislaw Gruszka <sgruszka(a)redhat.com>
---
drivers/net/wireless/iwlwifi/iwl-tx.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-tx.c b/drivers/net/wireless/iwlwifi/iwl-tx.c
index f449f06..cf5ac00 100644
--- a/drivers/net/wireless/iwlwifi/iwl-tx.c
+++ b/drivers/net/wireless/iwlwifi/iwl-tx.c
@@ -1096,7 +1096,6 @@ int iwl_tx_queue_reclaim(struct iwl_priv *priv, int txq_id, int index)
priv->cfg->ops->lib->txq_inval_byte_cnt_tbl(priv, txq);
priv->cfg->ops->lib->txq_free_tfd(priv, txq);
- nfreed++;
}
return nfreed;
}
--
1.6.2.5
14 years, 1 month
PROBLEM: crash on halt with 2.6.34-0.16.rc2.git0.fc14.x86_64
by Jon Masters
No analysis yet. Just passing this along.
Jon.
--- begin oops log ---
Halting system...
BUG: unable to handle kernel NULL pointer dereference at
0000000000000004
IP: [<ffffffff81017e7b>] amd_pmu_cpu_offline+0x38/0x6b
PGD 741d5067 PUD 77715067 PMD 0
Oops: 0000 [#1] SMP
last sysfs file: /sys/devices/virtual/block/dm-1/dm/name
CPU 0
Modules linked in: sit tunnel4 tun sunrpc powernow_k8 freq_table bridge
stp llc nf_conntrack_netbios_ns ip6t_REJECT nf_conntrack_ipv6 ipv6
kvm_amd kvm uinput snd_hda_codec_realtek snd_hda_intel snd_hda_codec
snd_hwdep snd_seq snd_seq_device snd_pcm ppdev parport_pc parport r8169
snd_timer mii snd edac_core soundcore microcode serio_raw snd_page_alloc
edac_mce_amd k8temp i2c_nforce2 hwmon ata_generic pata_acpi
firewire_ohci firewire_core crc_itu_t floppy sata_nv pata_amd nouveau
ttm drm_kms_helper drm i2c_algo_bit i2c_core [last unloaded:
cpufreq_ondemand]
Pid: 2792, comm: halt Not tainted 2.6.34-0.16.rc2.git0.fc14.x86_64 #1
www.abit.com.tw /System Product Name
RIP: 0010:[<ffffffff81017e7b>] [<ffffffff81017e7b>] amd_pmu_cpu_offline
+0x38/0x6b
RSP: 0018:ffff880024289ca8 EFLAGS: 00010292
RAX: ffff880024124900 RBX: ffff88000520cc70 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffffffff81017e74 RDI: ffffffff81488830
RBP: ffff880024289cb8 R08: 0000000000000002 R09: 0000000000000000
R10: 0000000000000046 R11: ffffe8ffffc01980 R12: 00000000fffffffd
R13: ffffffff81ac70c0 R14: 0000000000000001 R15: 0000000000000000
FS: 00007f7ec4f8a700(0000) GS:ffff880005000000(0000)
knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000004 CR3: 0000000077381000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process halt (pid: 2792, threadinfo ffff880024288000, task
ffff880024124900)
Stack:
ffff880024289cb8 0000000000000017 ffff880024289cc8 ffffffff8147fbb0
<0> ffff880024289d18 ffffffff8148dede 0000000000000001 ffffffffa0294020
<0> ffff880024289d28 0000000000000001 ffffffff81ba1de0 0000000000000010
Call Trace:
[<ffffffff8147fbb0>] x86_pmu_notifier+0x52/0x59
[<ffffffff8148dede>] notifier_call_chain+0x68/0x9c
[<ffffffff81070b21>] raw_notifier_call_chain+0x14/0x16
[<ffffffff81471efc>] _cpu_down+0x1bb/0x2bf
[<ffffffff81051d71>] disable_nonboot_cpus+0x7a/0x112
[<ffffffff8106593e>] kernel_power_off+0x26/0x40
[<ffffffff81065c02>] sys_reboot+0x126/0x1b2
[<ffffffff811316bf>] ? __d_free+0x56/0x5a
[<ffffffff811316fa>] ? d_free+0x37/0x50
[<ffffffff81138ad0>] ? mntput_no_expire+0x2c/0xfd
[<ffffffff81122ab7>] ? __fput+0x1d0/0x1df
[<ffffffff8111f7b8>] ? sys_close+0x32/0x10f
[<ffffffff81129fb7>] ? path_put+0x22/0x27
[<ffffffff810a875a>] ? audit_syscall_entry+0x11e/0x14a
[<ffffffff81489c15>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[<ffffffff81009c72>] system_call_fastpath+0x16/0x1b
Code: 76 b8 00 01 76 54 48 63 ff 48 c7 c3 70 cc 00 00 48 03 1c fd 40 fa
b9 81 48 c7 c7 40 b5 a4 81 e8 f9 1f 47 00 48 8b 93 28 07 00 00 <8b> 42
04 ff c8 85 c0 89 42 04 75 0c 48 8b bb 28 07 00 00 e8 b5
RIP [<ffffffff81017e7b>] amd_pmu_cpu_offline+0x38/0x6b
RSP <ffff880024289ca8>
CR2: 0000000000000004
---[ end trace 7d3f5b5a80d53cb0 ]---
init: rc main process (2792) killed by KILL signal
14 years, 1 month
Changing default module options
by Stanislaw Gruszka
Hi
I would like to change default iwlagn/iwl3945 options (swcrypto50=1
swcrypto=1) to solve two nasty iwlwifi firmware bugs.
What is preferred way to do this by changing /etc/modprobe.d/
or by patching kernel?
Stanislaw
14 years, 1 month
Re: rpms/kernel/devel linux-2.6-cantiga-iommu-gfx.patch, 1.1, 1.2 kernel.spec, 1.1947, 1.1948
by Kyle McMartin
On Fri, Mar 19, 2010 at 12:37:35PM +0000, David Woodhouse wrote:
> Author: dwmw2
>
> Update of /cvs/pkgs/rpms/kernel/devel
> In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv5720
>
> Modified Files:
> kernel.spec
> Added Files:
> linux-2.6-cantiga-iommu-gfx.patch
> Log Message:
> Fix #538163 again
>
You know, if you'd put the patch upstream, you wouldn't have to do this.
It's not like this is a Fedora specific bug.
regards, Kyle
14 years, 1 month
