date:20121025

arch/x86/Kconfig: not select X86_MPPARSE when SFI is present

2012-10-25 Thread Bin Gao

MPS tables are not needed for systems that have proper ACPI support.
This is also true for systems that have SFI in place.

So this patch is to exclude X86_MPPARSE when either ACPI or SFI is present.

Signed-off-by: Bin Gao bin@intel.com
---
 arch/x86/Kconfig |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 46c3bff..b1494bd 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -310,7 +310,7 @@ config X86_X2APIC
  If you don't know what to do here, say N.
 
 config X86_MPPARSE
-   bool Enable MPS table if ACPI
+   bool Enable MPS table if ACPI || SFI
default y
depends on X86_LOCAL_APIC
---help---
-- 
1.7.4.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [sqlite] light weight write barriers

2012-10-25 Thread Theodore Ts'o

On Thu, Oct 25, 2012 at 12:18:47AM -0500, Nico Williams wrote:
 
 By trusting fsync().  And if you don't care about immediate Durability
 you can run the fsync() in a background thread and mark the associated
 transaction as completed in the next transaction to be written after
 the fsync() completes.

The challenge is when you have entagled metadata updates.  That is,
you update file A, and file B, and file A and B might share metadata.
In order to sync file A, you also have to update part of the metadata
for the updates to file B, which means calculating the dependencies of
what you have to drag in can get very complicated.  You can keep track
of what bits of the metadata you have to undo and then redo before
writing out the metadata for fsync(A), but that basically means you
have to implement soft updates, and all of the complexity this
implies: http://lwn.net/Articles/339337/

If you can keep all of the metadata separate, this can be somewhat
mitigated, but usually the block allocation records (regardless of
whether you use a tree, or a bitmap, or some other data structure)
tends of have entanglement problems.

It certainly is not impossible; RDBMS's have implemented this.  On the
other hand, they generally aren't as fast as file systems for
non-transactional workloads, and people really care about performance
on those sorts of workloads for file systems.  (About a decade ago,
Oracle tried to claim that you could run file system workloads using
an Oracle databsae as a back-end.  Everyone laughed at them, and the
idea died a quick, merciful death.)

Still, if you want to try to implement such a thing, by all means,
give it a try.  But I think you'll find that creating a file system
that can compete with existing file systems for performance, and
*then* also supports a transactional model, is going to be quite a
challenge.

 - Ted
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Kdump with signed images

2012-10-25 Thread Mimi Zohar

On Wed, 2012-10-24 at 13:36 -0400, Vivek Goyal wrote:
On Tue, Oct 23, 2012 at 09:19:27AM -0700, Eric W. Biederman wrote:
Vivek Goyal vgo...@redhat.com writes:

On Tue, Oct 23, 2012 at 09:18:54AM -0400, Vivek Goyal wrote:

[..]
There are 3 options for trusting /sbin/kexec. There are IMA and
EMA,
and it is conceivable to have ELF note sections with signatures for
executables.

Can you please tell more about what is EMA and IMA. I did quick
google
and could not find much.

That should have been EVM and IMA. Look under security/integrity/. I
don't know much about them but they appear to be security modules with
a
focus on verifying checksum or perhaps encrypted hashes of executables
are consistent.

I will do some quick search there and I see if I can understand
something.

Ok, I quickly went through following paper.

http://mirror.transact.net.au/sourceforge/l/project/li/linux-ima/linux-ima/Integrity_overview.pdf

So it looks like that IMA can store the hashes of files and at execute
time ensure those hashes are unchanged to protect against the possibility
of modification of files.

IMA-appraisal originally was hashed based, but Dmitry Kasatkin added
digital signature support. Both have been upstreamed.

But what about creation of a new program which can call kexec_load()
and execute an unsigned kernel. Doesn't look like that will be
prevented using IMA.

Assuming the IMA policy syntax is updated to require 'security.ima' to
contain a digital signature, then it is only a question of protecting
the _ima and _evm keyrings. (Dmitry has such a patch waiting to be
reviewed.) So the new program would have to be vetted by someone
trusted.

Whole idea behind UEFI secure boot seems to be that all signing happens
outside the running system and now only signed code can run with higher
priviliges.

No. UEFI secure boot has absolutely nothing todo with this.

UEFI secure boot is about not being able to hijack the code EFI runs
directly. Full stop.

Some people would like to implment a security policy that says
you can't boot an untrusted version of windows from linux if you have
booted with UEFI secure boot, so they don't get their bootloader
signatures revoked by microsoft.

A security model relying on Microsoft's key is totally uniteresting to
me. Either signing at the UEFI level is of no use or Microsofts key
will fall again to the combined assult of every cracker and every
governmental dirty cyber ops division attacking it. Not to mention that
Microsoft has little incentive to keep linux booting.

I think it is reasonable to be able to support a policy where we can't
boot unsigned versions of Microsoft windows. However beyond being able
to exclude booting windows being one criteria for our policy mechanism
please don't even start to justify things with that ridiculous security
policy even indirectly.

IMA seems to be only protecting against only making sure
existing binaries are not modifed but it does not seem to prevent against
installation of new binaries and these binaries take advantage of kexec
system call to load an unsigned kernel.

The IMA/IMA-appraisal policy dictates what needs to be appraised. The
default ima-appraisal policy appraises all files owned by root.

I believe you can combine IMA with EVM signed security attributes where
the EVM signing key is offline, and the verification key is in the
kernel.

The combination of IMA and EVM gets very close to being able to sign
executables offline and be able to update them.

[ Again CCing lkml and IMA/EVM folks ]

After little reading, my understanding is EVM also does not support
offline signing.

http://sourceforge.net/apps/mediawiki/linux-ima/index.php?title=Main_Page

Given the fact EVM protects IMA data (security.ima), which is generated
inline, I am not sure how EVM can sign images offline.

I might have misunderstood things, please correct me if that's not the
case.

Thanks
Vivek

IMA-appraisal verifies the integrity of file data, while EVM verifies
the integrity of the file metadata, such as LSM and IMA-appraisal
labels. Both 'security.ima' and 'security.evm' can contain digital
signatures.

thanks,

Mimi

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

1 2 3 4 5 6 7 8 9 10 >

1 - 100 of 1720 matches

Mail list logo