Re: kdbus and Fedora
On Wed, 2015-07-08 at 13:02 -0400, Josh Boyer wrote:
On Wed, Jul 8, 2015 at 12:50 PM, Kevin Fenzi ke...@scrye.com wrote:
On Wed, 8 Jul 2015 10:32:53 -0400
Josh Boyer jwbo...@fedoraproject.org wrote:
I just pushed this to git and started a build. It will be in
rawhide
tomorrow with the 4.2.0-0.rc1.git2.1 kernel. (I was waiting for
rc1
before adding it.)
I did test both with and without kdbus=1 and both worked at least
from
a boot standpoint. The initramfs on an install lacks the kdbus
module, so it needs to be rebuilt if one wishes to use kdbus.
Seems to work here with the following issues/bugs/whatever:
- cpu usage is really high, seems to mostly be firewalld doing
something that generates audit messages and those spewing to the
journal. This drives the load on my laptop up to 5-6 or so and
cpu
fans spinning.
I noticed this as well.
- selinux isn't happy with things:
Jul 08 10:32:08 voldemort.scrye.com audit[1086]: AVC avc: denied
{ connectto } for pid=1086 comm=sedispatch
path=/run/dbus/system_bus_socket
scontext=system_u:system_r:audisp_t:s0
tcontext=system_u:system_r:init_t:s0 tclass=unix_stream_socket
permissive=0
Where should we report bugs for this work?
Hm, tough call. Perhaps against systemd unless it's a kernel oops?
I
would think systemd might need to set SELinux to permissive if it's
booting in kdbus mode until kdbus works with SELinux upstream.
File a bug with selinux-policy. Current policy allows:
allow audisp_t system_dbusd_t : unix_stream_socket connectto ;
But the thing on the other side of /run/dbus/system_bus_socket is no
longer system_dbus_t it is init_t...
Is that actually pid=1 on the other side, or something else that we
should just get labeled correctly in policy?
___
kernel mailing list
kernel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/kernel
mmap_min_addr
I notice that on x86_64 we set CONFIG_DEFAULT_MMAP_MIN_ADDR=4096 CONFIG_LSM_MMAP_MIN_ADDR=65536 I think we should be defaulting the DAC based protection to 64k as well (or dropping the LSM value to 4k). I guess the Kconfig default is 4k but testing when we wrote this feature said ia64, ppc64 and x86 could safely be 64k arm and maybe others should only be 32k If it is safe to run with SELinux enforcing 64k it should be safe to run with root/non-root enforcing 64k... ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
Re: [Fedora 09/19] binfmt_elf: Elf executable signature verification
On Wed, 2013-09-04 at 21:37 -0400, Josh Boyer wrote: +config BINFMT_ELF_SIG + bool ELF binary signature verification + depends on BINFMT_ELF + select INTEGRITY + select INTEGRITY_SIGNATURE + select INTEGRITY_ASYMMETRIC_KEYS + select IMA + select IMA_APPRAISE + select SYSTEM_TRUSTED_KEYRING + default n + ---help--- + Check ELF binary signature verfication. Please don't do this. Yes, it's technically viable to select all the things you need, but this turns on entire subsystems we don't have enabled. In months when the maintainers have long forgotten about this, we have to go figure out what turned on INTEGRITY and IMA because they aren't explicitly set in the config-* fragments. It's really frustrating. And it's just plain wrong. CONFIG_IMA requires CONFIG_TCG_TPM. But select is not recursive. So can end up with a config where IMA is on, but TPM is off... ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
Re: please enable CONFIG_AUDIT_LOGINUID_IMMUTABLE
On Mon, 2013-02-18 at 13:38 -0500, Tom Callaway wrote: On 02/18/2013 01:32 PM, Eric Paris wrote: On Mon, 2013-02-18 at 13:15 -0500, Josh Boyer wrote: On Mon, Feb 18, 2013 at 06:07:08PM +0100, Michal Schmidt wrote: Hello Fedora kernel maintainers, please consider setting CONFIG_AUDIT_LOGINUID_IMMUTABLE=y for F19. It brings a security benefit and should be safe to turn on since we're using systemd to start services. Refresh my memory please. Are we using systemd to start 100% of the services provided in Fedora? I seem to recall there are still a number of packages not using/providing systemd unit files. Would enabling this cause them to get weird EPERM errors? Is there a simple thing to check for aside from EPERM if issues from this do pop up? Daemons with a config requiring pam_lognuid.so will be unable to work if they are launched by a logged in admin as opposed to systemd. Obvious work around is to change the pam config. Login daemons launched by sysinit at boot will work. Login daemons launched by systemd will work. Login daemons launched by sysint from a logged in admin will fail. Assuming that systemd launching an old sysvinit script will work, this should be safe. I do not believe Fedora contains any other viable init mechanisms anymore (upstart is gone, sysvinit is a husk). What breaks is admin running /usr/sbin/sshd -D or /usr/sbin/crond -n unless they redo their stock pam config... stuff from systemd is going to work fine... ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
Re: please enable CONFIG_AUDIT_LOGINUID_IMMUTABLE
On Mon, 2013-02-18 at 14:28 -0500, Josh Boyer wrote: On Mon, Feb 18, 2013 at 01:42:09PM -0500, Eric Paris wrote: On Mon, 2013-02-18 at 13:38 -0500, Tom Callaway wrote: On 02/18/2013 01:32 PM, Eric Paris wrote: On Mon, 2013-02-18 at 13:15 -0500, Josh Boyer wrote: On Mon, Feb 18, 2013 at 06:07:08PM +0100, Michal Schmidt wrote: Hello Fedora kernel maintainers, please consider setting CONFIG_AUDIT_LOGINUID_IMMUTABLE=y for F19. It brings a security benefit and should be safe to turn on since we're using systemd to start services. Refresh my memory please. Are we using systemd to start 100% of the services provided in Fedora? I seem to recall there are still a number of packages not using/providing systemd unit files. Would enabling this cause them to get weird EPERM errors? Is there a simple thing to check for aside from EPERM if issues from this do pop up? Daemons with a config requiring pam_lognuid.so will be unable to work if they are launched by a logged in admin as opposed to systemd. Obvious work around is to change the pam config. Login daemons launched by sysinit at boot will work. Login daemons launched by systemd will work. Login daemons launched by sysint from a logged in admin will fail. Assuming that systemd launching an old sysvinit script will work, this should be safe. I do not believe Fedora contains any other viable init mechanisms anymore (upstart is gone, sysvinit is a husk). What breaks is admin running /usr/sbin/sshd -D or /usr/sbin/crond -n unless they redo their stock pam config... And there's no way we can fix the stock pam config so they don't have to do that? A more pointed question is, when people complain this stops working and the R word starts getting thrown around, can I point them at you and Michal? Sure, throw em at me :) -Eric ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
Re: Fwd: [PATCH] ARM: Fix restoration of IP scratch register when auditing syscalls
On Mon, 2012-04-30 at 12:47 -0400, Josh Boyer wrote: On Sun, Apr 29, 2012 at 02:40:01AM -0400, Jon Masters wrote: Going to assume you forwarded this here because you want it applied to the Fedora kernel. Likely F17/rawhide? I'm guessing we probably want to follow http://lists.infradead.org/pipermail/linux-arm-kernel/2012-April/096951.html for a bit to see if there are any more iterations of this? Since it's CC'd to stable, it should get picked up rather quickly if RMK applies it. You probably want to follow this thread as it's where an ARM developer actually looked at it :) http://lists.infradead.org/pipermail/linux-arm-kernel/2012-April/097002.html -Eric ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
[PATCH] SELinux: apply a different permission to ptrace a child vs non-child
Some applications, like gdb, are able to ptrace both children or other
completely unrelated tasks. We would like to be able to discern these two
things and to be able to allow gdb to ptrace it's children, but not to be
able to ptrace unrelated tasks for security reasons.
Upstream is a bit weary of this patch as it may be incomplete. They are
not fundamentally opposed to the patch, I was just ask to see if I could
flush out any needed refinement in Fedora where we already had the
problem. We may find that we need to emulate the YAMA non-child
registration module in order to completely deal with 'normal' ptrace on
a system. At the moment however, this patch will at least let us get
gdb working for many users in Fedora (See fedora-devel-list for a
discussion of the current issues people are complaining about in F17
without this)
---
security/selinux/hooks.c| 38 +++
security/selinux/include/classmap.h |2 +-
security/selinux/include/security.h |2 ++
security/selinux/selinuxfs.c|3 ++-
security/selinux/ss/services.c |3 +++
5 files changed, 46 insertions(+), 2 deletions(-)
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 1a4acf4..b226f26 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -1805,6 +1805,39 @@ static inline u32 open_file_to_av(struct file *file)
/* Hook functions begin here. */
+/**
+ * task_is_descendant - walk up a process family tree looking for a match
+ * @parent: the process to compare against while walking up from child
+ * @child: the process to start from while looking upwards for parent
+ *
+ * Returns 1 if child is a descendant of parent, 0 if not.
+ */
+static int task_is_descendant(struct task_struct *parent,
+ struct task_struct *child)
+{
+ int rc = 0;
+ struct task_struct *walker = child;
+
+ if (!parent || !child)
+ return 0;
+
+ rcu_read_lock();
+ if (!thread_group_leader(parent))
+ parent = rcu_dereference(parent-group_leader);
+ while (walker-pid 0) {
+ if (!thread_group_leader(walker))
+ walker = rcu_dereference(walker-group_leader);
+ if (walker == parent) {
+ rc = 1;
+ break;
+ }
+ walker = rcu_dereference(walker-real_parent);
+ }
+ rcu_read_unlock();
+
+ return rc;
+}
+
static int selinux_ptrace_access_check(struct task_struct *child,
unsigned int mode)
{
@@ -1820,6 +1853,9 @@ static int selinux_ptrace_access_check(struct task_struct
*child,
return avc_has_perm(sid, csid, SECCLASS_FILE, FILE__READ, NULL);
}
+
+ if (selinux_policycap_ptrace_child task_is_descendant(current,
child))
+ return current_has_perm(child, PROCESS__PTRACE_CHILD);
return current_has_perm(child, PROCESS__PTRACE);
}
@@ -1831,6 +1867,8 @@ static int selinux_ptrace_traceme(struct task_struct
*parent)
if (rc)
return rc;
+ if (selinux_policycap_ptrace_child task_is_descendant(parent,
current))
+ return task_has_perm(parent, current, PROCESS__PTRACE_CHILD);
return task_has_perm(parent, current, PROCESS__PTRACE);
}
diff --git a/security/selinux/include/classmap.h
b/security/selinux/include/classmap.h
index 39e678c..72c08b9 100644
--- a/security/selinux/include/classmap.h
+++ b/security/selinux/include/classmap.h
@@ -29,7 +29,7 @@ struct security_class_mapping secclass_map[] = {
getattr, setexec, setfscreate, noatsecure, siginh,
setrlimit, rlimitinh, dyntransition, setcurrent,
execmem, execstack, execheap, setkeycreate,
- setsockcreate, NULL } },
+ setsockcreate, ptrace_child, NULL } },
{ system,
{ ipc_info, syslog_read, syslog_mod,
syslog_console, module_request, NULL } },
diff --git a/security/selinux/include/security.h
b/security/selinux/include/security.h
index dde2005..ac14b0a 100644
--- a/security/selinux/include/security.h
+++ b/security/selinux/include/security.h
@@ -68,12 +68,14 @@ extern int selinux_enabled;
enum {
POLICYDB_CAPABILITY_NETPEER,
POLICYDB_CAPABILITY_OPENPERM,
+ POLICYDB_CAPABILITY_PTRACE_CHILD,
__POLICYDB_CAPABILITY_MAX
};
#define POLICYDB_CAPABILITY_MAX (__POLICYDB_CAPABILITY_MAX - 1)
extern int selinux_policycap_netpeer;
extern int selinux_policycap_openperm;
+extern int selinux_policycap_ptrace_child;
/*
* type_datum properties
diff --git a/security/selinux/selinuxfs.c b/security/selinux/selinuxfs.c
index 4e93f9e..3379765 100644
--- a/security/selinux/selinuxfs.c
+++ b/security/selinux/selinuxfs.c
@@ -44,7 +44,8 @@
/* Policy capability filenames */
static char *policycap_names[] = {
network_peer_controls,
- open_perms
+
enable CONFIG_AUDIT_LOGINUID_IMMUTABLE on F17
In F17 I'd like to see CONFIG_AUDIT_LOGINUID_IMMUTABLE turned on. In the old days when an admin restarted a service they actually did the restart themselves. Thus the new daemon would be attributed to the loginuid of the admin. If this daemon was ssh, when a new user logged in we needed a method to 'switch' the loginuid so the audit trail was associated with this new user, not the admin who started sshd. With the advent of systemd admins do not directly launch daemons and instead init launches it on their behalf. With this option set sshd will not need to 'switch' its loginuid, instead it will 'set' it for the first time. Even after a restart. This couldn't work under sysvinit or upstart, but since Fedora has removed almost all init scripts, noone can be using sysvinit or upstart any more! With this enabled we will break people directly launching login utilities instead of going through init. However it will allow us to remove some permissions from applications (CAP_AUDIT_CONTROL) since setting the loginuid will no longer be a privileged operation and will greatly increase the reliability of audit logs to be able to attest to what user performed what operation. -Eric ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
Re: enable CONFIG_AUDIT_LOGINUID_IMMUTABLE on F17
On Thu, 2012-02-09 at 14:32 -0500, Eric Paris wrote: With this enabled we will break people directly launching login utilities instead of going through init. However it will allow us to remove some permissions from applications (CAP_AUDIT_CONTROL) since setting the loginuid will no longer be a privileged operation and will greatly increase the reliability of audit logs to be able to attest to what user performed what operation. Launching by hand can be made to work by changing your pam config to switch pam_loginuid.so to be 'optional' instead of 'required.' It also means that the admin who started the service will be attributed to everything someone who logs in did. but those are the knocks if you do weird stuff like launch your own sshd inside a chroot ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
Re: grubby fatal error: unable to find a suitable template
On Tue, 2011-12-20 at 09:35 -0500, Don Zickus wrote: On Mon, Dec 19, 2011 at 05:56:42PM -0500, Steve Dickson wrote: # rpm -ihv kernel-3.2.0-0.rc6.git0.1.pnfsdlexp.fc16.x86_64.rpm Preparing...### [100%] 1:kernel ### [100%] grubby fatal error: unable to find a suitable template # uname -r 3.1.5-6.fc16.x86_64 My experience with the upgrading to F16 was the new grub2 was causing the problems. However, the way the install scripts were written, they update both grub.conf (grub1) and grub2.cfg (grub2). grub.conf is updated correctly, it is just the grub2.cfg isn't (in fact it is empty, hence the warning). Because my system still uses grub1 in the bootloader (not sure how to force it to use grub2), everything boots fine for me (for now :-/ ). So I just ignore the warning. My box had the exact opposite problem, I'm not using grub2. On upgrade to F16 grub1 (/boot/grub/grub.conf) was blank but grub2 (/boot/grub2/grub.cfg) worked just fine. Deleting grub.conf caused it to stop whining about being unable to find a template and now all is well. In my case (and Don's it sounds like) this was completely cosmetic... -Eric ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
Re: ima: use of radix tree cache indexing == massive waste of memory?
On Mon, 2010-10-18 at 10:56 -0700, Linus Torvalds wrote: On Mon, Oct 18, 2010 at 9:48 AM, Eric Paris epa...@redhat.com wrote: 1) IMA uses radix trees which end up wasting 500 bytes per inode because the key is too sparse. I've got a patch which uses an rbtree instead I'm testing and will send along shortly. I found it funny working on the patch to see that Documentation/rbtree.txt says This differs from radix trees (which are used to efficiently store sparse arrays and thus use long integer indexes to insert/access/delete nodes) Which flys in the face of this report. Please. Look at the report more carefully. The radix tree memory use is disgusting. Yes. But it is absolutely NOT sufficient to try to just fix that part. Go back, look at the original report email, and this line in particular: 2235648 2069791 92%0.12K 69864 32279456K iint_cache There's 2.2 million iint_cache allocations too, each 128 bytes in size. That's still a quarter _gigabyte_ of crap that adds zero value at all. That was #2 in my list of things to fix: 2) IMA creates an entire integrity structure for every inode even when most or all of this structure will not be needed. I'm stating with #1 since that was 2G of wasted space (thus far my switch to rbtree seems to be surviving an xfstest) so I expect to send the patch this afternoon. #2 should attack the size of the iint_cache entries. #3 should attack the scalability. I'm certainly hoping I didn't miss part of the report -Eric ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
Re: up'ing /proc/sys/fs/inotify/max_user_watches ?
On Thu, 2010-08-12 at 12:01 -0500, Rex Dieter wrote: kde packagers received a request to consider shipping systems with a higher (default) value of /proc/sys/fs/inotify/max_user_watches to allow for a better experience for noticing changes (notably when using nepomuk indexing of content in users' homedir). The suggested value was something like 524288 (seems the default on f13 is 8192). A recent kde-sig meeting discussed the topic, http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2010-07-27 where mjg59 also agreed It's probably justifiable to increase it. So, any comments or objections implementing this (for f14)? I'm not opposed to it but this does allow used to allocate and hold kernel memory. The math is roughly 200 bytes per watch. So right now a normal user can only allocate about 200*8192 bytes which is about 1.6M of kernel memory. Not such a bad thing. Your suggestion would allow the user to allocate 200 * 524288 = 105M. On a 64bit system this might not matter, but on a 32bit system this is a substantial amount of the memory the kernel has. And these allocations are not counted against normal userspace limits. I'm not opposed to upping it, especially on x86_64, but maybe not quite that high -Eric ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
Re: up'ing /proc/sys/fs/inotify/max_user_watches ?
On Tue, 2010-08-17 at 12:45 -0400, Dave Jones wrote: On Tue, Aug 17, 2010 at 12:41:48PM -0400, Eric Paris wrote: On Thu, 2010-08-12 at 12:01 -0500, Rex Dieter wrote: kde packagers received a request to consider shipping systems with a higher (default) value of /proc/sys/fs/inotify/max_user_watches to allow for a better experience for noticing changes (notably when using nepomuk indexing of content in users' homedir). The suggested value was something like 524288 (seems the default on f13 is 8192). A recent kde-sig meeting discussed the topic, http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2010-07-27 where mjg59 also agreed It's probably justifiable to increase it. So, any comments or objections implementing this (for f14)? I'm not opposed to it but this does allow used to allocate and hold kernel memory. The math is roughly 200 bytes per watch. So right now a normal user can only allocate about 200*8192 bytes which is about 1.6M of kernel memory. Not such a bad thing. Your suggestion would allow the user to allocate 200 * 524288 = 105M. On a 64bit system this might not matter, but on a 32bit system this is a substantial amount of the memory the kernel has. And these allocations are not counted against normal userspace limits. I'm not opposed to upping it, especially on x86_64, but maybe not quite that high ideally, when an application that cares about this is installed, it could increase it via sysctl.conf That default isn't a one size fits all. Regardless of what we set it to, someone is going to want it smaller/bigger. I think we want to be very careful how much we suggest $random-package muck with sysctl. Ubuntu got a black eye since wine automatically changed mmap_min_addr if it was installed. It's not always clear what the implications of a change include. How many people on this list (the kernel list) would have guessed that the suggestion here would allow 5-10 users completely DoS a 32 machine? Rex, if you do decide to change it in sysctl lets try to keep it within a factor of 10 or so? You might want to ask the upstream kernel community what they think. -Eric ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
Re: enable CONFIG_INTEL_TXT
On Wed, 2010-03-31 at 16:43 -0400, Tom spot Callaway wrote: On 03/31/2010 04:40 PM, Eric Paris wrote: Are there any objections to enabling CONFIG_INTEL_TXT on x86_64? We don't traditionally enable kernel config options for functionality that we have no intention (or capacity) to natively support in Fedora. But we have both the intention and hopefully the capacity to make this easily used by some people if they so chose. But this is step one. I'm willing to bet that we will see tboot submitted as a Fedora package after this first step is overcome. A TPM hardened disk encryption key is something which is interesting and which I hope to be able to work on. Seeing as how Fedora has no plans to utilize TPM, I don't think we should take this action, as it would merely imply a level of support for this functionality that we will not be able to provide. Fedora ALREADY utilizes the TPM. Maybe you missed that. Take a look at the TPM drivers and IMA in kernel along with trousers and tpmdd in userspace. Given that users who wish to use INTEL_TXT will need to make other customizations to their system environment in order to use it, I don't see why they can't make a custom kernel to go with it. There is a huge difference between installing a userspace RPM and rebuilding a kernel. Although not insurmountable it is silly to provide tools to make use of TXT (trousers which we ALREADY HAVE in fedora) but not allow our users to turn it on. I'm of the opinion that we shouldn't be enabling dead code chunks at random, especially not in situations like this where the primary use is to encourage vendor utilization of closed source binary blobs what are these binary blobs of which you speak? I thought this was well covered. No binary blobs. or trusting a hardware vendor in matters of encryption. So I should assume that Fedora has a policy against the new Intel AES instructions? That's going to be interesting. ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
Re: enable CONFIG_INTEL_TXT
On Thu, 2010-04-01 at 08:51 +1100, James Morris wrote: On Wed, 31 Mar 2010, Eric Paris wrote: 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. My feeling is that this needs to be dealt with upstream, and that the open source tboot needs to be delivered first. Done and done. We are turning on an upstream config option. Are there any objections to enabling CONFIG_INTEL_TXT on x86_64? Yes. - We should be doing kernel development upstream unless there's an extraordinary reason not to (typically, following a request from Linus). Done... - We should not be adding kernel infrastructure to support proprietary, closed source We aren't... - Especially so, given that this is a security feature I'd love to see support for TXT -- I think we can do some very important things with it, but I don't think it's workable as open source if it depends on closed proprietary code. What is this code you speak of? -Eric ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
Re: enable CONFIG_INTEL_TXT
On Thu, 2010-04-01 at 09:24 +1100, James Morris wrote: On Wed, 31 Mar 2010, Eric Paris wrote: 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.) Also, why is there no chance of this being open sourced? Simple answer is 'because Intel says so.' I'm sorry but I don't think I'm allowed to divulge any reasons Intel may or may not have shared with Red Hat. I will say that a large sticking point is the fact that even if it was open source the requirement that it be signed by an Intel key to function would still have made the SINIT AC module unacceptable to fedora. Something so closely tied to hardware needs to be dealt with by the hardware vendors and IBM has agreed to take that step. -Eric ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
Re: enable CONFIG_INTEL_TXT
On Thu, 2010-04-01 at 09:15 +1100, James Morris wrote: On Wed, 31 Mar 2010, Eric Paris wrote: On Thu, 2010-04-01 at 08:51 +1100, James Morris wrote: On Wed, 31 Mar 2010, Eric Paris wrote: 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. My feeling is that this needs to be dealt with upstream, and that the open source tboot needs to be delivered first. Done and done. We are turning on an upstream config option. Interesting -- looks like this went in without any signoffs from security folk. The last I recall upstream was objecting to the binary blob aspect. I'd love to see support for TXT -- I think we can do some very important things with it, but I don't think it's workable as open source if it depends on closed proprietary code. What is this code you speak of? You mention 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 Does TXT still depend on this proprietary blob? If you choose to purchase certain hardware, such as the IBM system X referenced in the discussion there is no need for any proprietary blobs as the system takes care of supplying everything that is needed for it to function. Some older laptops and desktop chipsets might be able to be made to work with a closed source binary blob signed by Intel. So no, TXT does not still depend on a separate proprietary blob you need to go and download. But the use of such a blob is not precluded if you as a user make that choice to enable functionality of your existing system. -Eric ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
