Menu
▾
▴
linux-ima-user — Q&A for users of IMA
This list is closed, nobody may subscribe to it.
| 2007 |
Jan
|
Feb
(10) |
Mar
(26) |
Apr
(8) |
May
(3) |
Jun
|
Jul
(26) |
Aug
(10) |
Sep
|
Oct
|
Nov
(2) |
Dec
(4) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
|
Feb
(13) |
Mar
(4) |
Apr
(3) |
May
(5) |
Jun
|
Jul
(7) |
Aug
(8) |
Sep
(5) |
Oct
(16) |
Nov
|
Dec
(6) |
| 2009 |
Jan
(2) |
Feb
|
Mar
(3) |
Apr
|
May
|
Jun
(19) |
Jul
(4) |
Aug
|
Sep
(13) |
Oct
(10) |
Nov
(12) |
Dec
(2) |
| 2010 |
Jan
|
Feb
(2) |
Mar
(17) |
Apr
(28) |
May
|
Jun
(17) |
Jul
(11) |
Aug
(12) |
Sep
(2) |
Oct
|
Nov
|
Dec
(1) |
| 2011 |
Jan
|
Feb
|
Mar
(20) |
Apr
(10) |
May
(1) |
Jun
|
Jul
|
Aug
(15) |
Sep
(14) |
Oct
(2) |
Nov
|
Dec
|
| 2012 |
Jan
(1) |
Feb
(53) |
Mar
(15) |
Apr
(4) |
May
(2) |
Jun
(13) |
Jul
|
Aug
|
Sep
(12) |
Oct
|
Nov
|
Dec
(6) |
| 2013 |
Jan
(7) |
Feb
(8) |
Mar
(4) |
Apr
(5) |
May
|
Jun
|
Jul
|
Aug
(5) |
Sep
(6) |
Oct
|
Nov
(5) |
Dec
(8) |
| 2014 |
Jan
(17) |
Feb
(24) |
Mar
(8) |
Apr
(7) |
May
(18) |
Jun
(15) |
Jul
(5) |
Aug
(2) |
Sep
(49) |
Oct
(28) |
Nov
(7) |
Dec
(30) |
| 2015 |
Jan
(40) |
Feb
|
Mar
(9) |
Apr
(2) |
May
(9) |
Jun
(31) |
Jul
(33) |
Aug
(5) |
Sep
(20) |
Oct
|
Nov
(3) |
Dec
(12) |
| 2016 |
Jan
(14) |
Feb
(29) |
Mar
(10) |
Apr
(4) |
May
(4) |
Jun
|
Jul
(5) |
Aug
(19) |
Sep
(21) |
Oct
(2) |
Nov
(36) |
Dec
(30) |
| 2017 |
Jan
(101) |
Feb
(12) |
Mar
(7) |
Apr
(2) |
May
(29) |
Jun
(22) |
Jul
(7) |
Aug
(93) |
Sep
(27) |
Oct
(39) |
Nov
|
Dec
|
|
From: Dmitry K. <d.k...@sa...> - 2014-02-17 08:26:15
|
On 14/02/14 17:06, Mimi Zohar wrote:
> On Fri, 2014-02-14 at 13:21 +0000, Lipinski, MarekX wrote:
>>> On 12/02/14 16:09, Mimi Zohar wrote:
>>>> I guess we'll find out. :) Is there any reason for attempting to load
>>>> a kernel module, when hmac(sha1) should be built in? We really want
>>>> to skip the modprobe entirely. Wondering what would happen if the
>>>> modprobe proc entry was NULL... It looks like the modprobe would be
>>> skipped.
>>>> The last line of crypto/api.c: crypto_larval_lookup() will simply call
>>>> crypto_larval_add() to add it.
>>> I actually have the same deadlock problem on Tizen platform when not using
>>> initramfs.
>> I tried to go through the crypto API and understand the process of
>> registering algorithms but it looks bit complex to me.
> I'm guessing the modprobe is to find HW versions, before using the
> builtin one.
>
>>> For hacking purpose and not to mess up with modprobe I just added
>> this at
>>> the beginning of the evm_init_key().
>>> (...)
>> Other workaround, without modifying the code, is to build-in trusted
>> keys as they register hmac(sha1) during initialization stage.
> Yes, but without an initramfs, it would be using the system's modprobe.
>
>>> But in real system, you still need to enable IMA/EVM BEFORE reading
>>> anything from storage....
>>> initramfs is one of the choices...
>> My plan is to inject the secured key inside the kernel during boot. I
>> hope that will work fine.
> A 'real' solution will need to be compatible with secure boot. I'm not
> sure this solution would be.
>
>> Regarding EVM I'm wondering why the hash/hmac algorithm is initialized
>> and freed every time the calculation is requested (init_desc/kfree). I
>> noticed that in IMA this approach was changed around 3.9 to single
>> initialization at startup. Wouldn't it bring performance improvement
>> if EVM is implemented the same way? Also for trusted keys crypto
>> algorithm initialization is done once, during startup.
> Will add to the 'todo' list...
>
> thanks,
>
> Mimi
>
>
Hello,
In fact very early EVM code did preloading of crypto alg.
That was done probably due to this reason.
And executing modprobe before EVM is initialized is as safe as executing
EVM initialization script itself.
The bottom line is that nothing has to be executed from "unverified"
storage before IMA/EVM is initialized.
- Dmitry
------------------------------------------------------
+static struct crypto_hash *tfm_hmac; /* preload crypto alg */
+static int __init init_evm(void)
+{
+ int error;
+
+ tfm_hmac = crypto_alloc_hash(evm_hmac, 0, CRYPTO_ALG_ASYNC);
+ error = evm_init_secfs();
+ if (error < 0) {
+ printk(KERN_INFO "EVM: Error registering secfs\n");
+ goto err;
+ }
+err:
+ return error;
+}
+
--------------------------------------------------------------------------------
|
|
From: Mimi Z. <zo...@li...> - 2014-02-14 15:07:12
|
On Fri, 2014-02-14 at 13:21 +0000, Lipinski, MarekX wrote: > > On 12/02/14 16:09, Mimi Zohar wrote: > > > I guess we'll find out. :) Is there any reason for attempting to load > > > a kernel module, when hmac(sha1) should be built in? We really want > > > to skip the modprobe entirely. Wondering what would happen if the > > > modprobe proc entry was NULL... It looks like the modprobe would be > > skipped. > > > The last line of crypto/api.c: crypto_larval_lookup() will simply call > > > crypto_larval_add() to add it. > > I actually have the same deadlock problem on Tizen platform when not using > > initramfs. > > I tried to go through the crypto API and understand the process of > registering algorithms but it looks bit complex to me. I'm guessing the modprobe is to find HW versions, before using the builtin one. > > For hacking purpose and not to mess up with modprobe I just added > this at > > the beginning of the evm_init_key(). > > (...) > > Other workaround, without modifying the code, is to build-in trusted > keys as they register hmac(sha1) during initialization stage. Yes, but without an initramfs, it would be using the system's modprobe. > > But in real system, you still need to enable IMA/EVM BEFORE reading > > anything from storage.... > > initramfs is one of the choices... > > My plan is to inject the secured key inside the kernel during boot. I > hope that will work fine. A 'real' solution will need to be compatible with secure boot. I'm not sure this solution would be. > Regarding EVM I'm wondering why the hash/hmac algorithm is initialized > and freed every time the calculation is requested (init_desc/kfree). I > noticed that in IMA this approach was changed around 3.9 to single > initialization at startup. Wouldn't it bring performance improvement > if EVM is implemented the same way? Also for trusted keys crypto > algorithm initialization is done once, during startup. Will add to the 'todo' list... thanks, Mimi |
|
From: Lipinski, M. <mar...@in...> - 2014-02-14 13:22:14
|
> On 12/02/14 16:09, Mimi Zohar wrote: > > I guess we'll find out. :) Is there any reason for attempting to load > > a kernel module, when hmac(sha1) should be built in? We really want > > to skip the modprobe entirely. Wondering what would happen if the > > modprobe proc entry was NULL... It looks like the modprobe would be > skipped. > > The last line of crypto/api.c: crypto_larval_lookup() will simply call > > crypto_larval_add() to add it. > I actually have the same deadlock problem on Tizen platform when not using > initramfs. I tried to go through the crypto API and understand the process of registering algorithms but it looks bit complex to me. > For hacking purpose and not to mess up with modprobe I just added this at > the beginning of the evm_init_key(). > (...) Other workaround, without modifying the code, is to build-in trusted keys as they register hmac(sha1) during initialization stage. > But in real system, you still need to enable IMA/EVM BEFORE reading > anything from storage.... > initramfs is one of the choices... My plan is to inject the secured key inside the kernel during boot. I hope that will work fine. Regarding EVM I'm wondering why the hash/hmac algorithm is initialized and freed every time the calculation is requested (init_desc/kfree). I noticed that in IMA this approach was changed around 3.9 to single initialization at startup. Wouldn't it bring performance improvement if EVM is implemented the same way? Also for trusted keys crypto algorithm initialization is done once, during startup. Regards, Marek Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk Registergericht: Muenchen HRB 47456 Ust.-IdNr./VAT Registration No.: DE129385895 Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052 |
|
From: Dmitry K. <d.k...@sa...> - 2014-02-13 09:51:59
|
On 12/02/14 16:09, Mimi Zohar wrote:
> On Wed, 2014-02-12 at 13:50 +0000, Lipinski, MarekX wrote:
>> I forgot to mention - I do not use initramfs/initrd.
>>
>> Normally it may not make sense to use hash based security without
>> having initramfs. However the plan is to protect evm-key in different,
>> platform-specific way.
>>
>> Altgough I think hash based IMA/EVM without ram disk is still legal,
>> isn't it?
> I guess we'll find out. :) Is there any reason for attempting to load
> a kernel module, when hmac(sha1) should be built in? We really want to
> skip the modprobe entirely. Wondering what would happen if the modprobe
> proc entry was NULL... It looks like the modprobe would be skipped.
> The last line of crypto/api.c: crypto_larval_lookup() will simply call
> crypto_larval_add() to add it.
>
> thanks,
>
> Mimi
>
>
I actually have the same deadlock problem on Tizen platform when not
using initramfs.
For hacking purpose and not to mess up with modprobe I just added this
at the beginning of the evm_init_key().
-----------------------------------------------------------------------------
struct shash_desc *desc;
/* this is a hack to check if hmac(sha1) is a problem */
desc = init_desc(EVM_XATTR_HMAC);
if (IS_ERR(desc)) {
pr_info("EVM: init_desc failed\n");
return PTR_ERR(desc);
}
kfree(desc);
-----------------------------------------------------------------------------
It will pre-load hmac(sha1) before enabling EVM.
But in real system, you still need to enable IMA/EVM BEFORE reading
anything from storage....
initramfs is one of the choices...
But we will find better solution...
- Dmitry
|
|
From: Mimi Z. <zo...@li...> - 2014-02-12 14:10:29
|
On Wed, 2014-02-12 at 13:50 +0000, Lipinski, MarekX wrote: > I forgot to mention - I do not use initramfs/initrd. > > Normally it may not make sense to use hash based security without > having initramfs. However the plan is to protect evm-key in different, > platform-specific way. > > Altgough I think hash based IMA/EVM without ram disk is still legal, > isn't it? I guess we'll find out. :) Is there any reason for attempting to load a kernel module, when hmac(sha1) should be built in? We really want to skip the modprobe entirely. Wondering what would happen if the modprobe proc entry was NULL... It looks like the modprobe would be skipped. The last line of crypto/api.c: crypto_larval_lookup() will simply call crypto_larval_add() to add it. thanks, Mimi |
|
From: Lipinski, M. <mar...@in...> - 2014-02-12 13:50:48
|
I forgot to mention - I do not use initramfs/initrd. Normally it may not make sense to use hash based security without having initramfs. However the plan is to protect evm-key in different, platform-specific way. Altgough I think hash based IMA/EVM without ram disk is still legal, isn't it? Regards, Marek -----Original Message----- From: Mimi Zohar [mailto:zo...@li...] Sent: Wednesday, February 12, 2014 2:06 PM To: Lipinski, MarekX Cc: lin...@li...; Dmitry Kasatkin Subject: Re: [Linux-ima-user] Deadlock after enabling EVM in fix mode On Wed, 2014-02-12 at 08:41 +0000, Lipinski, MarekX wrote: > Hi Mimi, > > I never used signatures - just hashes. Thanks to Dimitry I noticed that hmac(sha1) is not automatically registering at boot time (is not listed in /proc/crypto). > > It seems that the scenario is as follows: > 1) kernel boots - no registration of hmac(sha1) > 2) init script loads evm-key > 3) init script starts evm > 4) init script tries to execute any other binary > a) evm is to verify the hash of the 'other binary' > b) evm initializes hmac algorithm > c) algorithm initialization calls request_module > d) request_module before accessing /sbin/modprobe does evm verification > e) since the verification is called from the context of other > verification function stops on mutext lock > > The kernel I'm using is 3.8.0 Ok. Looking at kernel/kmod.c, the default modprobe path is /sbin/modprobe, which would be the initramfs. I'm not seeing the problem, since some other module dracut copies modprobe to the initramfs. (The initramfs is not appraised.) The EVM dracut module should have its own dependency on modprobe. thanks, Mimi Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk Registergericht: Muenchen HRB 47456 Ust.-IdNr./VAT Registration No.: DE129385895 Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052 |
|
From: Mimi Z. <zo...@li...> - 2014-02-12 13:06:12
|
On Wed, 2014-02-12 at 08:41 +0000, Lipinski, MarekX wrote: > Hi Mimi, > > I never used signatures - just hashes. Thanks to Dimitry I noticed that hmac(sha1) is not automatically registering at boot time (is not listed in /proc/crypto). > > It seems that the scenario is as follows: > 1) kernel boots - no registration of hmac(sha1) > 2) init script loads evm-key > 3) init script starts evm > 4) init script tries to execute any other binary > a) evm is to verify the hash of the 'other binary' > b) evm initializes hmac algorithm > c) algorithm initialization calls request_module > d) request_module before accessing /sbin/modprobe does evm verification > e) since the verification is called from the context of other verification function stops on mutext lock > > The kernel I'm using is 3.8.0 Ok. Looking at kernel/kmod.c, the default modprobe path is /sbin/modprobe, which would be the initramfs. I'm not seeing the problem, since some other module dracut copies modprobe to the initramfs. (The initramfs is not appraised.) The EVM dracut module should have its own dependency on modprobe. thanks, Mimi |
|
From: Lipinski, M. <mar...@in...> - 2014-02-12 08:41:30
|
Hi Mimi, I never used signatures - just hashes. Thanks to Dimitry I noticed that hmac(sha1) is not automatically registering at boot time (is not listed in /proc/crypto). It seems that the scenario is as follows: 1) kernel boots - no registration of hmac(sha1) 2) init script loads evm-key 3) init script starts evm 4) init script tries to execute any other binary a) evm is to verify the hash of the 'other binary' b) evm initializes hmac algorithm c) algorithm initialization calls request_module d) request_module before accessing /sbin/modprobe does evm verification e) since the verification is called from the context of other verification function stops on mutext lock The kernel I'm using is 3.8.0 Regards, Marek -----Original Message----- From: Mimi Zohar [mailto:zo...@li...] Sent: Wednesday, February 12, 2014 12:25 AM To: Dmitry Kasatkin Cc: Lipinski, MarekX; lin...@li... Subject: Re: [Linux-ima-user] Deadlock after enabling EVM in fix mode Hi Marek, Sorry, I can't seem to reproduce this problem. I have EVM, IMA, IMA-appraisal, and encrypted-keys enabled (builtin), but not trusted-keys. Assuming modprobe is signed, not hashed, have you loaded the public keys on the _ima and _evm keyrings, before enabling EVM? The public keys should be included in the initramfs. Lastly, which kernel are you using? thanks, Mimi On Mon, 2014-02-10 at 11:07 +0200, Dmitry Kasatkin wrote: > Hi, > > Thanks for great help. > We will fix it. > > - Dmitry > > On 07/02/14 17:37, Lipinski, MarekX wrote: > > I found out I had CONFIG_TRUSTED_KEYS not set (as I do not have TPM in my box). > > I enabled trusted keys in the configuration. Now once init is reached hmac(sha1) is already registered and EVM works fine, no deadlock anymore. > > I guess either EVM support should depend on TRUSTED_KEYS, or the registration of hmac(sha1) should be enforced before enabing EVM. > > > > Regards, > > Marek Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk Registergericht: Muenchen HRB 47456 Ust.-IdNr./VAT Registration No.: DE129385895 Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052 |
|
From: Mimi Z. <zo...@li...> - 2014-02-11 23:25:16
|
Hi Marek, Sorry, I can't seem to reproduce this problem. I have EVM, IMA, IMA-appraisal, and encrypted-keys enabled (builtin), but not trusted-keys. Assuming modprobe is signed, not hashed, have you loaded the public keys on the _ima and _evm keyrings, before enabling EVM? The public keys should be included in the initramfs. Lastly, which kernel are you using? thanks, Mimi On Mon, 2014-02-10 at 11:07 +0200, Dmitry Kasatkin wrote: > Hi, > > Thanks for great help. > We will fix it. > > - Dmitry > > On 07/02/14 17:37, Lipinski, MarekX wrote: > > I found out I had CONFIG_TRUSTED_KEYS not set (as I do not have TPM in my box). > > I enabled trusted keys in the configuration. Now once init is reached hmac(sha1) is already registered and EVM works fine, no deadlock anymore. > > I guess either EVM support should depend on TRUSTED_KEYS, or the registration of hmac(sha1) should be enforced before enabing EVM. > > > > Regards, > > Marek |
|
From: Dmitry K. <d.k...@sa...> - 2014-02-10 09:09:19
|
Hi, Thanks for great help. We will fix it. - Dmitry On 07/02/14 17:37, Lipinski, MarekX wrote: > I found out I had CONFIG_TRUSTED_KEYS not set (as I do not have TPM in my box). > I enabled trusted keys in the configuration. Now once init is reached hmac(sha1) is already registered and EVM works fine, no deadlock anymore. > I guess either EVM support should depend on TRUSTED_KEYS, or the registration of hmac(sha1) should be enforced before enabing EVM. > > Regards, > Marek > > -----Original Message----- > From: Dmitry Kasatkin [mailto:d.k...@sa...] > Sent: Friday, February 07, 2014 4:11 PM > To: Lipinski, MarekX; lin...@li... > Subject: Re: [Linux-ima-user] Deadlock after enabling EVM in fix mode > > Ok. > > So hmac(sha1) is not registered. > > You can also look if /proc/crypto has sha1 itself... > > I have to look and recall how hmac function is constructed... > > - Dmitry > > On 07/02/14 16:52, Lipinski, MarekX wrote: >> Hi, >> >> The name of the crypto algoritm that causes deadlock is hmac(sha1) - this is the name passed to crypto_larval_lookup. >> It's not loaded before enabling EVM (i.e. it's not in /proc/crypto). >> What is loaded is only hmac(sha256): >> name : hmac(sha256) >> driver : hmac(sha256-generic) >> >> >From the printouts I added I see that after request_module is called ima_appraise_measurement identifies that /sbin/modprobe integrity status is INTEGRITY_NOLABEL and cause "missing-HMAC" (due to missing securit.evm attr). This causes ima_fix_xattr to be called, which initiates xattr change procedure. >> What's wired the same steps are run 3 times. >> >> Regards, >> Marek >> >> -----Original Message----- >> From: Dmitry Kasatkin [mailto:d.k...@sa...] >> Sent: Friday, February 07, 2014 2:26 PM >> To: Lipinski, MarekX; lin...@li... >> Subject: Re: [Linux-ima-user] Deadlock after enabling EVM in fix mode >> >> Hi, >> >> Your boot flow sounds like normal.... I have the same. >> So a bit weired... Never got such deadlock. >> >> May be before echo 1 >security/evm >> you could 'grep hmac /proc/crypto' to see if hmac and sha1 are there? >> >> name : hmac(sha1) >> driver : hmac(sha1-generic) >> >> Are you able to add few prints to crypto_larval_lookup()? >> >> What is the "name" value? >> >> - Dmitry >> >> >> On 07/02/14 14:58, Lipinski, MarekX wrote: >>> Hi Dimitry, >>> >>> They're both compiled-in: >>> CONFIG_CRYPTO_HMAC=y >>> CONFIG_CRYPTO_SHA1=y >>> >>> It seems that the function crypto_larval_lookup calls request_module regardles the fact the algorithm is compiled in. >>> It's done always of the first run of the function (for a specifig algorithm), when crypto_alg_lookup fails. >>> >>> Regards, >>> Marek >>> >>> -----Original Message----- >>> From: Lipinski, MarekX >>> Sent: Friday, February 07, 2014 1:10 PM >>> To: 'lin...@li...' >>> Subject: Deadlock after enabling EVM in fix mode >>> >>> Hi, >>> >>> I'm trying to enable IMA/EVM on my box. I'm experiencing problems in the following situation: >>> System is booted with rootflags=i_version ima_appraise_tcb ima_appraise=fix evm=fix. >>> EVM is being enabled at the very begining of the booting. Init script (passed to the kernel) mounts /sys, /proc, /dev, loads the emv-key file and starts the EVM by echoing "1" into /sys/kernel/security/evm. Untill now everything is ok and I'm getting 'EVM: initialized' message. >>> >>> After that running any other executable causes the deadlock. It looks as if before execution EVM tries to calculate the HMAC. init_desc function is being called, which tries to load hmac(sha1) algorithm. Crypto API calls request_module, which tries to run /sbin/modprobe. Before executing modprobe executable is being verified To have correct EVM HMAC. This again causes the init_desc to be executed and hang on the mutex_lock. >>> >>> Can anyone tell me what I'm doing wrong? >>> >>> The only workaround that comes to my mind is to force evms init_desc to be run before evm is enabled so the algorithm is loaded and any subsequent call will not require requesting module. >>> >>> Kernel debug message: >>> >>> [ 90.993569] INFO: task modprobe:110 blocked for more than 30 seconds. >>> [ 91.000801] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. >>> [ 91.009576] modprobe D 00000000 0 110 109 0x00000000 >>> [ 91.016754] f3051cac 00000046 00000249 00000000 f30783b0 c182a200 c16e3000 c182a200 >>> [ 91.025632] 2bdcc63b 00000008 2ae91efb 00000008 f30783b0 f3051c64 00000006 00000019 >>> [ 91.034514] 00000001 00000000 c11be254 f30783b0 c192b8b4 00000040 f30783b0 00000001 >>> [ 91.043371] Call Trace: >>> [ 91.046137] [<c11be254>] ? trace_hardirqs_on_thunk+0xc/0x10 >>> [ 91.052491] [<c10722c3>] ? mark_held_locks+0xae/0xd0 >>> [ 91.058163] [<c14201cb>] ? mutex_lock_nested+0x152/0x2a2 >>> [ 91.064288] [<c1421517>] schedule+0x51/0x53 >>> [ 91.069086] [<c1421712>] schedule_preempt_disabled+0x12/0x1e >>> [ 91.075534] [<c14201e7>] mutex_lock_nested+0x16e/0x2a2 >>> [ 91.081399] [<c1195f7e>] ? init_desc+0x52/0x177 >>> [ 91.086585] [<c1195f7e>] init_desc+0x52/0x177 >>> [ 91.091576] [<c1196144>] evm_calc_hmac_or_hash+0x47/0xed >>> [ 91.097636] [<c10f3404>] ? vfs_getxattr_alloc+0x8d/0xa9 >>> [ 91.103598] [<c11961fa>] evm_calc_hmac+0x10/0x12 >>> [ 91.108880] [<c1195ccf>] evm_verify_hmac+0xdd/0x149 >>> [ 91.114468] [<c102cac7>] ? vprintk_emit+0x391/0x3cf >>> [ 91.120042] [<c1195dcd>] evm_verifyxattr+0x53/0x63 >>> [ 91.125520] [<c11958fc>] ima_appraise_measurement+0xaa/0x1b9 >>> [ 91.131970] [<c1194b39>] process_measurement+0x13d/0x182 >>> [ 91.138021] [<c1194ce8>] ima_file_check+0x16a/0x182 >>> [ 91.143597] [<c10e2962>] do_last.clone.26+0x7c1/0x90e >>> [ 91.149355] [<c10e0145>] ? inode_permission+0x3f/0x41 >>> [ 91.155123] [<c10e01ac>] ? link_path_walk+0x65/0x670 >>> [ 91.160793] [<c10e2b44>] path_openat.clone.27+0x95/0x352 >>> [ 91.166852] [<c1070107>] ? trace_hardirqs_off+0xb/0xd >>> [ 91.172619] [<c10e3022>] do_filp_open+0x21/0x5d >>> [ 91.177805] [<c10edd68>] ? __alloc_fd+0x178/0x183 >>> [ 91.183185] [<c10d769c>] do_sys_open+0x104/0x17d >>> [ 91.188468] [<c10d7736>] sys_open+0x21/0x29 >>> [ 91.193265] [<c1422ffe>] sysenter_do_call+0x12/0x36 >>> >>> >>> The kernel I'm using is 3.8.0 >>> >>> Thanks, >>> Marek >>> Intel GmbH >>> Dornacher Strasse 1 >>> 85622 Feldkirchen/Muenchen, Deutschland Sitz der Gesellschaft: >>> Feldkirchen bei Muenchen >>> Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas >>> Lusk >>> Registergericht: Muenchen HRB 47456 >>> Ust.-IdNr./VAT Registration No.: DE129385895 Citibank Frankfurt a.M. >>> (BLZ 502 109 00) 600119052 >>> >>> >>> --------------------------------------------------------------------- >>> - >>> -------- Managing the Performance of Cloud-Based Applications Take >>> advantage of what the Cloud has to offer - Avoid Common Pitfalls. >>> Read the Whitepaper. >>> http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg. >>> clktrk _______________________________________________ >>> Linux-ima-user mailing list >>> Lin...@li... >>> https://lists.sourceforge.net/lists/listinfo/linux-ima-user >>> >> Intel GmbH >> Dornacher Strasse 1 >> 85622 Feldkirchen/Muenchen, Deutschland Sitz der Gesellschaft: >> Feldkirchen bei Muenchen >> Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas >> Lusk >> Registergericht: Muenchen HRB 47456 >> Ust.-IdNr./VAT Registration No.: DE129385895 Citibank Frankfurt a.M. >> (BLZ 502 109 00) 600119052 >> >> >> ---------------------------------------------------------------------- >> -------- Managing the Performance of Cloud-Based Applications Take >> advantage of what the Cloud has to offer - Avoid Common Pitfalls. >> Read the Whitepaper. >> http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg. >> clktrk _______________________________________________ >> Linux-ima-user mailing list >> Lin...@li... >> https://lists.sourceforge.net/lists/listinfo/linux-ima-user >> > Intel GmbH > Dornacher Strasse 1 > 85622 Feldkirchen/Muenchen, Deutschland > Sitz der Gesellschaft: Feldkirchen bei Muenchen > Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk > Registergericht: Muenchen HRB 47456 > Ust.-IdNr./VAT Registration No.: DE129385895 > Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052 > > > ------------------------------------------------------------------------------ > Managing the Performance of Cloud-Based Applications > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. > Read the Whitepaper. > http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk > _______________________________________________ > Linux-ima-user mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux-ima-user > > |
|
From: Mimi Z. <zo...@li...> - 2014-02-09 18:14:05
|
On Fri, 2014-02-07 at 15:37 +0000, Lipinski, MarekX wrote: > I found out I had CONFIG_TRUSTED_KEYS not set (as I do not have TPM in my box). > I enabled trusted keys in the configuration. Now once init is reached hmac(sha1) is already > registered and EVM works fine, no deadlock anymore. I guess either EVM support should depend > on TRUSTED_KEYS, or the registration of hmac(sha1) should be enforced before enabing EVM. Thanks MarekX for the bug report. Now that IMA supports large digests, this issue might be more pervasive than just EVM's dependency on SHA1. thanks, Mimi |
|
From: Lipinski, M. <mar...@in...> - 2014-02-07 15:38:21
|
I found out I had CONFIG_TRUSTED_KEYS not set (as I do not have TPM in my box). I enabled trusted keys in the configuration. Now once init is reached hmac(sha1) is already registered and EVM works fine, no deadlock anymore. I guess either EVM support should depend on TRUSTED_KEYS, or the registration of hmac(sha1) should be enforced before enabing EVM. Regards, Marek -----Original Message----- From: Dmitry Kasatkin [mailto:d.k...@sa...] Sent: Friday, February 07, 2014 4:11 PM To: Lipinski, MarekX; lin...@li... Subject: Re: [Linux-ima-user] Deadlock after enabling EVM in fix mode Ok. So hmac(sha1) is not registered. You can also look if /proc/crypto has sha1 itself... I have to look and recall how hmac function is constructed... - Dmitry On 07/02/14 16:52, Lipinski, MarekX wrote: > Hi, > > The name of the crypto algoritm that causes deadlock is hmac(sha1) - this is the name passed to crypto_larval_lookup. > It's not loaded before enabling EVM (i.e. it's not in /proc/crypto). > What is loaded is only hmac(sha256): > name : hmac(sha256) > driver : hmac(sha256-generic) > > >From the printouts I added I see that after request_module is called ima_appraise_measurement identifies that /sbin/modprobe integrity status is INTEGRITY_NOLABEL and cause "missing-HMAC" (due to missing securit.evm attr). This causes ima_fix_xattr to be called, which initiates xattr change procedure. > What's wired the same steps are run 3 times. > > Regards, > Marek > > -----Original Message----- > From: Dmitry Kasatkin [mailto:d.k...@sa...] > Sent: Friday, February 07, 2014 2:26 PM > To: Lipinski, MarekX; lin...@li... > Subject: Re: [Linux-ima-user] Deadlock after enabling EVM in fix mode > > Hi, > > Your boot flow sounds like normal.... I have the same. > So a bit weired... Never got such deadlock. > > May be before echo 1 >security/evm > you could 'grep hmac /proc/crypto' to see if hmac and sha1 are there? > > name : hmac(sha1) > driver : hmac(sha1-generic) > > Are you able to add few prints to crypto_larval_lookup()? > > What is the "name" value? > > - Dmitry > > > On 07/02/14 14:58, Lipinski, MarekX wrote: >> Hi Dimitry, >> >> They're both compiled-in: >> CONFIG_CRYPTO_HMAC=y >> CONFIG_CRYPTO_SHA1=y >> >> It seems that the function crypto_larval_lookup calls request_module regardles the fact the algorithm is compiled in. >> It's done always of the first run of the function (for a specifig algorithm), when crypto_alg_lookup fails. >> >> Regards, >> Marek >> >> -----Original Message----- >> From: Lipinski, MarekX >> Sent: Friday, February 07, 2014 1:10 PM >> To: 'lin...@li...' >> Subject: Deadlock after enabling EVM in fix mode >> >> Hi, >> >> I'm trying to enable IMA/EVM on my box. I'm experiencing problems in the following situation: >> System is booted with rootflags=i_version ima_appraise_tcb ima_appraise=fix evm=fix. >> EVM is being enabled at the very begining of the booting. Init script (passed to the kernel) mounts /sys, /proc, /dev, loads the emv-key file and starts the EVM by echoing "1" into /sys/kernel/security/evm. Untill now everything is ok and I'm getting 'EVM: initialized' message. >> >> After that running any other executable causes the deadlock. It looks as if before execution EVM tries to calculate the HMAC. init_desc function is being called, which tries to load hmac(sha1) algorithm. Crypto API calls request_module, which tries to run /sbin/modprobe. Before executing modprobe executable is being verified To have correct EVM HMAC. This again causes the init_desc to be executed and hang on the mutex_lock. >> >> Can anyone tell me what I'm doing wrong? >> >> The only workaround that comes to my mind is to force evms init_desc to be run before evm is enabled so the algorithm is loaded and any subsequent call will not require requesting module. >> >> Kernel debug message: >> >> [ 90.993569] INFO: task modprobe:110 blocked for more than 30 seconds. >> [ 91.000801] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. >> [ 91.009576] modprobe D 00000000 0 110 109 0x00000000 >> [ 91.016754] f3051cac 00000046 00000249 00000000 f30783b0 c182a200 c16e3000 c182a200 >> [ 91.025632] 2bdcc63b 00000008 2ae91efb 00000008 f30783b0 f3051c64 00000006 00000019 >> [ 91.034514] 00000001 00000000 c11be254 f30783b0 c192b8b4 00000040 f30783b0 00000001 >> [ 91.043371] Call Trace: >> [ 91.046137] [<c11be254>] ? trace_hardirqs_on_thunk+0xc/0x10 >> [ 91.052491] [<c10722c3>] ? mark_held_locks+0xae/0xd0 >> [ 91.058163] [<c14201cb>] ? mutex_lock_nested+0x152/0x2a2 >> [ 91.064288] [<c1421517>] schedule+0x51/0x53 >> [ 91.069086] [<c1421712>] schedule_preempt_disabled+0x12/0x1e >> [ 91.075534] [<c14201e7>] mutex_lock_nested+0x16e/0x2a2 >> [ 91.081399] [<c1195f7e>] ? init_desc+0x52/0x177 >> [ 91.086585] [<c1195f7e>] init_desc+0x52/0x177 >> [ 91.091576] [<c1196144>] evm_calc_hmac_or_hash+0x47/0xed >> [ 91.097636] [<c10f3404>] ? vfs_getxattr_alloc+0x8d/0xa9 >> [ 91.103598] [<c11961fa>] evm_calc_hmac+0x10/0x12 >> [ 91.108880] [<c1195ccf>] evm_verify_hmac+0xdd/0x149 >> [ 91.114468] [<c102cac7>] ? vprintk_emit+0x391/0x3cf >> [ 91.120042] [<c1195dcd>] evm_verifyxattr+0x53/0x63 >> [ 91.125520] [<c11958fc>] ima_appraise_measurement+0xaa/0x1b9 >> [ 91.131970] [<c1194b39>] process_measurement+0x13d/0x182 >> [ 91.138021] [<c1194ce8>] ima_file_check+0x16a/0x182 >> [ 91.143597] [<c10e2962>] do_last.clone.26+0x7c1/0x90e >> [ 91.149355] [<c10e0145>] ? inode_permission+0x3f/0x41 >> [ 91.155123] [<c10e01ac>] ? link_path_walk+0x65/0x670 >> [ 91.160793] [<c10e2b44>] path_openat.clone.27+0x95/0x352 >> [ 91.166852] [<c1070107>] ? trace_hardirqs_off+0xb/0xd >> [ 91.172619] [<c10e3022>] do_filp_open+0x21/0x5d >> [ 91.177805] [<c10edd68>] ? __alloc_fd+0x178/0x183 >> [ 91.183185] [<c10d769c>] do_sys_open+0x104/0x17d >> [ 91.188468] [<c10d7736>] sys_open+0x21/0x29 >> [ 91.193265] [<c1422ffe>] sysenter_do_call+0x12/0x36 >> >> >> The kernel I'm using is 3.8.0 >> >> Thanks, >> Marek >> Intel GmbH >> Dornacher Strasse 1 >> 85622 Feldkirchen/Muenchen, Deutschland Sitz der Gesellschaft: >> Feldkirchen bei Muenchen >> Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas >> Lusk >> Registergericht: Muenchen HRB 47456 >> Ust.-IdNr./VAT Registration No.: DE129385895 Citibank Frankfurt a.M. >> (BLZ 502 109 00) 600119052 >> >> >> --------------------------------------------------------------------- >> - >> -------- Managing the Performance of Cloud-Based Applications Take >> advantage of what the Cloud has to offer - Avoid Common Pitfalls. >> Read the Whitepaper. >> http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg. >> clktrk _______________________________________________ >> Linux-ima-user mailing list >> Lin...@li... >> https://lists.sourceforge.net/lists/listinfo/linux-ima-user >> > Intel GmbH > Dornacher Strasse 1 > 85622 Feldkirchen/Muenchen, Deutschland Sitz der Gesellschaft: > Feldkirchen bei Muenchen > Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas > Lusk > Registergericht: Muenchen HRB 47456 > Ust.-IdNr./VAT Registration No.: DE129385895 Citibank Frankfurt a.M. > (BLZ 502 109 00) 600119052 > > > ---------------------------------------------------------------------- > -------- Managing the Performance of Cloud-Based Applications Take > advantage of what the Cloud has to offer - Avoid Common Pitfalls. > Read the Whitepaper. > http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg. > clktrk _______________________________________________ > Linux-ima-user mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux-ima-user > Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk Registergericht: Muenchen HRB 47456 Ust.-IdNr./VAT Registration No.: DE129385895 Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052 |
|
From: Dmitry K. <d.k...@sa...> - 2014-02-07 15:12:57
|
Ok. So hmac(sha1) is not registered. You can also look if /proc/crypto has sha1 itself... I have to look and recall how hmac function is constructed... - Dmitry On 07/02/14 16:52, Lipinski, MarekX wrote: > Hi, > > The name of the crypto algoritm that causes deadlock is hmac(sha1) - this is the name passed to crypto_larval_lookup. > It's not loaded before enabling EVM (i.e. it's not in /proc/crypto). > What is loaded is only hmac(sha256): > name : hmac(sha256) > driver : hmac(sha256-generic) > > >From the printouts I added I see that after request_module is called ima_appraise_measurement identifies that /sbin/modprobe integrity status is INTEGRITY_NOLABEL and cause "missing-HMAC" (due to missing securit.evm attr). This causes ima_fix_xattr to be called, which initiates xattr change procedure. > What's wired the same steps are run 3 times. > > Regards, > Marek > > -----Original Message----- > From: Dmitry Kasatkin [mailto:d.k...@sa...] > Sent: Friday, February 07, 2014 2:26 PM > To: Lipinski, MarekX; lin...@li... > Subject: Re: [Linux-ima-user] Deadlock after enabling EVM in fix mode > > Hi, > > Your boot flow sounds like normal.... I have the same. > So a bit weired... Never got such deadlock. > > May be before echo 1 >security/evm > you could 'grep hmac /proc/crypto' to see if hmac and sha1 are there? > > name : hmac(sha1) > driver : hmac(sha1-generic) > > Are you able to add few prints to crypto_larval_lookup()? > > What is the "name" value? > > - Dmitry > > > On 07/02/14 14:58, Lipinski, MarekX wrote: >> Hi Dimitry, >> >> They're both compiled-in: >> CONFIG_CRYPTO_HMAC=y >> CONFIG_CRYPTO_SHA1=y >> >> It seems that the function crypto_larval_lookup calls request_module regardles the fact the algorithm is compiled in. >> It's done always of the first run of the function (for a specifig algorithm), when crypto_alg_lookup fails. >> >> Regards, >> Marek >> >> -----Original Message----- >> From: Lipinski, MarekX >> Sent: Friday, February 07, 2014 1:10 PM >> To: 'lin...@li...' >> Subject: Deadlock after enabling EVM in fix mode >> >> Hi, >> >> I'm trying to enable IMA/EVM on my box. I'm experiencing problems in the following situation: >> System is booted with rootflags=i_version ima_appraise_tcb ima_appraise=fix evm=fix. >> EVM is being enabled at the very begining of the booting. Init script (passed to the kernel) mounts /sys, /proc, /dev, loads the emv-key file and starts the EVM by echoing "1" into /sys/kernel/security/evm. Untill now everything is ok and I'm getting 'EVM: initialized' message. >> >> After that running any other executable causes the deadlock. It looks as if before execution EVM tries to calculate the HMAC. init_desc function is being called, which tries to load hmac(sha1) algorithm. Crypto API calls request_module, which tries to run /sbin/modprobe. Before executing modprobe executable is being verified To have correct EVM HMAC. This again causes the init_desc to be executed and hang on the mutex_lock. >> >> Can anyone tell me what I'm doing wrong? >> >> The only workaround that comes to my mind is to force evms init_desc to be run before evm is enabled so the algorithm is loaded and any subsequent call will not require requesting module. >> >> Kernel debug message: >> >> [ 90.993569] INFO: task modprobe:110 blocked for more than 30 seconds. >> [ 91.000801] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. >> [ 91.009576] modprobe D 00000000 0 110 109 0x00000000 >> [ 91.016754] f3051cac 00000046 00000249 00000000 f30783b0 c182a200 c16e3000 c182a200 >> [ 91.025632] 2bdcc63b 00000008 2ae91efb 00000008 f30783b0 f3051c64 00000006 00000019 >> [ 91.034514] 00000001 00000000 c11be254 f30783b0 c192b8b4 00000040 f30783b0 00000001 >> [ 91.043371] Call Trace: >> [ 91.046137] [<c11be254>] ? trace_hardirqs_on_thunk+0xc/0x10 >> [ 91.052491] [<c10722c3>] ? mark_held_locks+0xae/0xd0 >> [ 91.058163] [<c14201cb>] ? mutex_lock_nested+0x152/0x2a2 >> [ 91.064288] [<c1421517>] schedule+0x51/0x53 >> [ 91.069086] [<c1421712>] schedule_preempt_disabled+0x12/0x1e >> [ 91.075534] [<c14201e7>] mutex_lock_nested+0x16e/0x2a2 >> [ 91.081399] [<c1195f7e>] ? init_desc+0x52/0x177 >> [ 91.086585] [<c1195f7e>] init_desc+0x52/0x177 >> [ 91.091576] [<c1196144>] evm_calc_hmac_or_hash+0x47/0xed >> [ 91.097636] [<c10f3404>] ? vfs_getxattr_alloc+0x8d/0xa9 >> [ 91.103598] [<c11961fa>] evm_calc_hmac+0x10/0x12 >> [ 91.108880] [<c1195ccf>] evm_verify_hmac+0xdd/0x149 >> [ 91.114468] [<c102cac7>] ? vprintk_emit+0x391/0x3cf >> [ 91.120042] [<c1195dcd>] evm_verifyxattr+0x53/0x63 >> [ 91.125520] [<c11958fc>] ima_appraise_measurement+0xaa/0x1b9 >> [ 91.131970] [<c1194b39>] process_measurement+0x13d/0x182 >> [ 91.138021] [<c1194ce8>] ima_file_check+0x16a/0x182 >> [ 91.143597] [<c10e2962>] do_last.clone.26+0x7c1/0x90e >> [ 91.149355] [<c10e0145>] ? inode_permission+0x3f/0x41 >> [ 91.155123] [<c10e01ac>] ? link_path_walk+0x65/0x670 >> [ 91.160793] [<c10e2b44>] path_openat.clone.27+0x95/0x352 >> [ 91.166852] [<c1070107>] ? trace_hardirqs_off+0xb/0xd >> [ 91.172619] [<c10e3022>] do_filp_open+0x21/0x5d >> [ 91.177805] [<c10edd68>] ? __alloc_fd+0x178/0x183 >> [ 91.183185] [<c10d769c>] do_sys_open+0x104/0x17d >> [ 91.188468] [<c10d7736>] sys_open+0x21/0x29 >> [ 91.193265] [<c1422ffe>] sysenter_do_call+0x12/0x36 >> >> >> The kernel I'm using is 3.8.0 >> >> Thanks, >> Marek >> Intel GmbH >> Dornacher Strasse 1 >> 85622 Feldkirchen/Muenchen, Deutschland Sitz der Gesellschaft: >> Feldkirchen bei Muenchen >> Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas >> Lusk >> Registergericht: Muenchen HRB 47456 >> Ust.-IdNr./VAT Registration No.: DE129385895 Citibank Frankfurt a.M. >> (BLZ 502 109 00) 600119052 >> >> >> ---------------------------------------------------------------------- >> -------- Managing the Performance of Cloud-Based Applications Take >> advantage of what the Cloud has to offer - Avoid Common Pitfalls. >> Read the Whitepaper. >> http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg. >> clktrk _______________________________________________ >> Linux-ima-user mailing list >> Lin...@li... >> https://lists.sourceforge.net/lists/listinfo/linux-ima-user >> > Intel GmbH > Dornacher Strasse 1 > 85622 Feldkirchen/Muenchen, Deutschland > Sitz der Gesellschaft: Feldkirchen bei Muenchen > Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk > Registergericht: Muenchen HRB 47456 > Ust.-IdNr./VAT Registration No.: DE129385895 > Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052 > > > ------------------------------------------------------------------------------ > Managing the Performance of Cloud-Based Applications > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. > Read the Whitepaper. > http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk > _______________________________________________ > Linux-ima-user mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux-ima-user > |
|
From: Lipinski, M. <mar...@in...> - 2014-02-07 14:52:54
|
Hi, The name of the crypto algoritm that causes deadlock is hmac(sha1) - this is the name passed to crypto_larval_lookup. It's not loaded before enabling EVM (i.e. it's not in /proc/crypto). What is loaded is only hmac(sha256): name : hmac(sha256) driver : hmac(sha256-generic) >From the printouts I added I see that after request_module is called ima_appraise_measurement identifies that /sbin/modprobe integrity status is INTEGRITY_NOLABEL and cause "missing-HMAC" (due to missing securit.evm attr). This causes ima_fix_xattr to be called, which initiates xattr change procedure. What's wired the same steps are run 3 times. Regards, Marek -----Original Message----- From: Dmitry Kasatkin [mailto:d.k...@sa...] Sent: Friday, February 07, 2014 2:26 PM To: Lipinski, MarekX; lin...@li... Subject: Re: [Linux-ima-user] Deadlock after enabling EVM in fix mode Hi, Your boot flow sounds like normal.... I have the same. So a bit weired... Never got such deadlock. May be before echo 1 >security/evm you could 'grep hmac /proc/crypto' to see if hmac and sha1 are there? name : hmac(sha1) driver : hmac(sha1-generic) Are you able to add few prints to crypto_larval_lookup()? What is the "name" value? - Dmitry On 07/02/14 14:58, Lipinski, MarekX wrote: > Hi Dimitry, > > They're both compiled-in: > CONFIG_CRYPTO_HMAC=y > CONFIG_CRYPTO_SHA1=y > > It seems that the function crypto_larval_lookup calls request_module regardles the fact the algorithm is compiled in. > It's done always of the first run of the function (for a specifig algorithm), when crypto_alg_lookup fails. > > Regards, > Marek > > -----Original Message----- > From: Lipinski, MarekX > Sent: Friday, February 07, 2014 1:10 PM > To: 'lin...@li...' > Subject: Deadlock after enabling EVM in fix mode > > Hi, > > I'm trying to enable IMA/EVM on my box. I'm experiencing problems in the following situation: > System is booted with rootflags=i_version ima_appraise_tcb ima_appraise=fix evm=fix. > EVM is being enabled at the very begining of the booting. Init script (passed to the kernel) mounts /sys, /proc, /dev, loads the emv-key file and starts the EVM by echoing "1" into /sys/kernel/security/evm. Untill now everything is ok and I'm getting 'EVM: initialized' message. > > After that running any other executable causes the deadlock. It looks as if before execution EVM tries to calculate the HMAC. init_desc function is being called, which tries to load hmac(sha1) algorithm. Crypto API calls request_module, which tries to run /sbin/modprobe. Before executing modprobe executable is being verified To have correct EVM HMAC. This again causes the init_desc to be executed and hang on the mutex_lock. > > Can anyone tell me what I'm doing wrong? > > The only workaround that comes to my mind is to force evms init_desc to be run before evm is enabled so the algorithm is loaded and any subsequent call will not require requesting module. > > Kernel debug message: > > [ 90.993569] INFO: task modprobe:110 blocked for more than 30 seconds. > [ 91.000801] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > [ 91.009576] modprobe D 00000000 0 110 109 0x00000000 > [ 91.016754] f3051cac 00000046 00000249 00000000 f30783b0 c182a200 c16e3000 c182a200 > [ 91.025632] 2bdcc63b 00000008 2ae91efb 00000008 f30783b0 f3051c64 00000006 00000019 > [ 91.034514] 00000001 00000000 c11be254 f30783b0 c192b8b4 00000040 f30783b0 00000001 > [ 91.043371] Call Trace: > [ 91.046137] [<c11be254>] ? trace_hardirqs_on_thunk+0xc/0x10 > [ 91.052491] [<c10722c3>] ? mark_held_locks+0xae/0xd0 > [ 91.058163] [<c14201cb>] ? mutex_lock_nested+0x152/0x2a2 > [ 91.064288] [<c1421517>] schedule+0x51/0x53 > [ 91.069086] [<c1421712>] schedule_preempt_disabled+0x12/0x1e > [ 91.075534] [<c14201e7>] mutex_lock_nested+0x16e/0x2a2 > [ 91.081399] [<c1195f7e>] ? init_desc+0x52/0x177 > [ 91.086585] [<c1195f7e>] init_desc+0x52/0x177 > [ 91.091576] [<c1196144>] evm_calc_hmac_or_hash+0x47/0xed > [ 91.097636] [<c10f3404>] ? vfs_getxattr_alloc+0x8d/0xa9 > [ 91.103598] [<c11961fa>] evm_calc_hmac+0x10/0x12 > [ 91.108880] [<c1195ccf>] evm_verify_hmac+0xdd/0x149 > [ 91.114468] [<c102cac7>] ? vprintk_emit+0x391/0x3cf > [ 91.120042] [<c1195dcd>] evm_verifyxattr+0x53/0x63 > [ 91.125520] [<c11958fc>] ima_appraise_measurement+0xaa/0x1b9 > [ 91.131970] [<c1194b39>] process_measurement+0x13d/0x182 > [ 91.138021] [<c1194ce8>] ima_file_check+0x16a/0x182 > [ 91.143597] [<c10e2962>] do_last.clone.26+0x7c1/0x90e > [ 91.149355] [<c10e0145>] ? inode_permission+0x3f/0x41 > [ 91.155123] [<c10e01ac>] ? link_path_walk+0x65/0x670 > [ 91.160793] [<c10e2b44>] path_openat.clone.27+0x95/0x352 > [ 91.166852] [<c1070107>] ? trace_hardirqs_off+0xb/0xd > [ 91.172619] [<c10e3022>] do_filp_open+0x21/0x5d > [ 91.177805] [<c10edd68>] ? __alloc_fd+0x178/0x183 > [ 91.183185] [<c10d769c>] do_sys_open+0x104/0x17d > [ 91.188468] [<c10d7736>] sys_open+0x21/0x29 > [ 91.193265] [<c1422ffe>] sysenter_do_call+0x12/0x36 > > > The kernel I'm using is 3.8.0 > > Thanks, > Marek > Intel GmbH > Dornacher Strasse 1 > 85622 Feldkirchen/Muenchen, Deutschland Sitz der Gesellschaft: > Feldkirchen bei Muenchen > Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas > Lusk > Registergericht: Muenchen HRB 47456 > Ust.-IdNr./VAT Registration No.: DE129385895 Citibank Frankfurt a.M. > (BLZ 502 109 00) 600119052 > > > ---------------------------------------------------------------------- > -------- Managing the Performance of Cloud-Based Applications Take > advantage of what the Cloud has to offer - Avoid Common Pitfalls. > Read the Whitepaper. > http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg. > clktrk _______________________________________________ > Linux-ima-user mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux-ima-user > Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk Registergericht: Muenchen HRB 47456 Ust.-IdNr./VAT Registration No.: DE129385895 Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052 |
|
From: Dmitry K. <d.k...@sa...> - 2014-02-07 13:27:21
|
Hi, Your boot flow sounds like normal.... I have the same. So a bit weired... Never got such deadlock. May be before echo 1 >security/evm you could 'grep hmac /proc/crypto' to see if hmac and sha1 are there? name : hmac(sha1) driver : hmac(sha1-generic) Are you able to add few prints to crypto_larval_lookup()? What is the "name" value? - Dmitry On 07/02/14 14:58, Lipinski, MarekX wrote: > Hi Dimitry, > > They're both compiled-in: > CONFIG_CRYPTO_HMAC=y > CONFIG_CRYPTO_SHA1=y > > It seems that the function crypto_larval_lookup calls request_module regardles the fact the algorithm is compiled in. > It's done always of the first run of the function (for a specifig algorithm), when crypto_alg_lookup fails. > > Regards, > Marek > > -----Original Message----- > From: Lipinski, MarekX > Sent: Friday, February 07, 2014 1:10 PM > To: 'lin...@li...' > Subject: Deadlock after enabling EVM in fix mode > > Hi, > > I'm trying to enable IMA/EVM on my box. I'm experiencing problems in the following situation: > System is booted with rootflags=i_version ima_appraise_tcb ima_appraise=fix evm=fix. > EVM is being enabled at the very begining of the booting. Init script (passed to the kernel) mounts /sys, /proc, /dev, loads the emv-key file and starts the EVM by echoing "1" into /sys/kernel/security/evm. Untill now everything is ok and I'm getting 'EVM: initialized' message. > > After that running any other executable causes the deadlock. It looks as if before execution EVM tries to calculate the HMAC. init_desc function is being called, which tries to load hmac(sha1) algorithm. Crypto API calls request_module, which tries to run /sbin/modprobe. Before executing modprobe executable is being verified To have correct EVM HMAC. This again causes the init_desc to be executed and hang on the mutex_lock. > > Can anyone tell me what I'm doing wrong? > > The only workaround that comes to my mind is to force evms init_desc to be run before evm is enabled so the algorithm is loaded and any subsequent call will not require requesting module. > > Kernel debug message: > > [ 90.993569] INFO: task modprobe:110 blocked for more than 30 seconds. > [ 91.000801] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > [ 91.009576] modprobe D 00000000 0 110 109 0x00000000 > [ 91.016754] f3051cac 00000046 00000249 00000000 f30783b0 c182a200 c16e3000 c182a200 > [ 91.025632] 2bdcc63b 00000008 2ae91efb 00000008 f30783b0 f3051c64 00000006 00000019 > [ 91.034514] 00000001 00000000 c11be254 f30783b0 c192b8b4 00000040 f30783b0 00000001 > [ 91.043371] Call Trace: > [ 91.046137] [<c11be254>] ? trace_hardirqs_on_thunk+0xc/0x10 > [ 91.052491] [<c10722c3>] ? mark_held_locks+0xae/0xd0 > [ 91.058163] [<c14201cb>] ? mutex_lock_nested+0x152/0x2a2 > [ 91.064288] [<c1421517>] schedule+0x51/0x53 > [ 91.069086] [<c1421712>] schedule_preempt_disabled+0x12/0x1e > [ 91.075534] [<c14201e7>] mutex_lock_nested+0x16e/0x2a2 > [ 91.081399] [<c1195f7e>] ? init_desc+0x52/0x177 > [ 91.086585] [<c1195f7e>] init_desc+0x52/0x177 > [ 91.091576] [<c1196144>] evm_calc_hmac_or_hash+0x47/0xed > [ 91.097636] [<c10f3404>] ? vfs_getxattr_alloc+0x8d/0xa9 > [ 91.103598] [<c11961fa>] evm_calc_hmac+0x10/0x12 > [ 91.108880] [<c1195ccf>] evm_verify_hmac+0xdd/0x149 > [ 91.114468] [<c102cac7>] ? vprintk_emit+0x391/0x3cf > [ 91.120042] [<c1195dcd>] evm_verifyxattr+0x53/0x63 > [ 91.125520] [<c11958fc>] ima_appraise_measurement+0xaa/0x1b9 > [ 91.131970] [<c1194b39>] process_measurement+0x13d/0x182 > [ 91.138021] [<c1194ce8>] ima_file_check+0x16a/0x182 > [ 91.143597] [<c10e2962>] do_last.clone.26+0x7c1/0x90e > [ 91.149355] [<c10e0145>] ? inode_permission+0x3f/0x41 > [ 91.155123] [<c10e01ac>] ? link_path_walk+0x65/0x670 > [ 91.160793] [<c10e2b44>] path_openat.clone.27+0x95/0x352 > [ 91.166852] [<c1070107>] ? trace_hardirqs_off+0xb/0xd > [ 91.172619] [<c10e3022>] do_filp_open+0x21/0x5d > [ 91.177805] [<c10edd68>] ? __alloc_fd+0x178/0x183 > [ 91.183185] [<c10d769c>] do_sys_open+0x104/0x17d > [ 91.188468] [<c10d7736>] sys_open+0x21/0x29 > [ 91.193265] [<c1422ffe>] sysenter_do_call+0x12/0x36 > > > The kernel I'm using is 3.8.0 > > Thanks, > Marek > Intel GmbH > Dornacher Strasse 1 > 85622 Feldkirchen/Muenchen, Deutschland > Sitz der Gesellschaft: Feldkirchen bei Muenchen > Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk > Registergericht: Muenchen HRB 47456 > Ust.-IdNr./VAT Registration No.: DE129385895 > Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052 > > > ------------------------------------------------------------------------------ > Managing the Performance of Cloud-Based Applications > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. > Read the Whitepaper. > http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk > _______________________________________________ > Linux-ima-user mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux-ima-user > |
|
From: Lipinski, M. <mar...@in...> - 2014-02-07 12:58:52
|
Hi Dimitry, They're both compiled-in: CONFIG_CRYPTO_HMAC=y CONFIG_CRYPTO_SHA1=y It seems that the function crypto_larval_lookup calls request_module regardles the fact the algorithm is compiled in. It's done always of the first run of the function (for a specifig algorithm), when crypto_alg_lookup fails. Regards, Marek -----Original Message----- From: Lipinski, MarekX Sent: Friday, February 07, 2014 1:10 PM To: 'lin...@li...' Subject: Deadlock after enabling EVM in fix mode Hi, I'm trying to enable IMA/EVM on my box. I'm experiencing problems in the following situation: System is booted with rootflags=i_version ima_appraise_tcb ima_appraise=fix evm=fix. EVM is being enabled at the very begining of the booting. Init script (passed to the kernel) mounts /sys, /proc, /dev, loads the emv-key file and starts the EVM by echoing "1" into /sys/kernel/security/evm. Untill now everything is ok and I'm getting 'EVM: initialized' message. After that running any other executable causes the deadlock. It looks as if before execution EVM tries to calculate the HMAC. init_desc function is being called, which tries to load hmac(sha1) algorithm. Crypto API calls request_module, which tries to run /sbin/modprobe. Before executing modprobe executable is being verified To have correct EVM HMAC. This again causes the init_desc to be executed and hang on the mutex_lock. Can anyone tell me what I'm doing wrong? The only workaround that comes to my mind is to force evms init_desc to be run before evm is enabled so the algorithm is loaded and any subsequent call will not require requesting module. Kernel debug message: [ 90.993569] INFO: task modprobe:110 blocked for more than 30 seconds. [ 91.000801] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 91.009576] modprobe D 00000000 0 110 109 0x00000000 [ 91.016754] f3051cac 00000046 00000249 00000000 f30783b0 c182a200 c16e3000 c182a200 [ 91.025632] 2bdcc63b 00000008 2ae91efb 00000008 f30783b0 f3051c64 00000006 00000019 [ 91.034514] 00000001 00000000 c11be254 f30783b0 c192b8b4 00000040 f30783b0 00000001 [ 91.043371] Call Trace: [ 91.046137] [<c11be254>] ? trace_hardirqs_on_thunk+0xc/0x10 [ 91.052491] [<c10722c3>] ? mark_held_locks+0xae/0xd0 [ 91.058163] [<c14201cb>] ? mutex_lock_nested+0x152/0x2a2 [ 91.064288] [<c1421517>] schedule+0x51/0x53 [ 91.069086] [<c1421712>] schedule_preempt_disabled+0x12/0x1e [ 91.075534] [<c14201e7>] mutex_lock_nested+0x16e/0x2a2 [ 91.081399] [<c1195f7e>] ? init_desc+0x52/0x177 [ 91.086585] [<c1195f7e>] init_desc+0x52/0x177 [ 91.091576] [<c1196144>] evm_calc_hmac_or_hash+0x47/0xed [ 91.097636] [<c10f3404>] ? vfs_getxattr_alloc+0x8d/0xa9 [ 91.103598] [<c11961fa>] evm_calc_hmac+0x10/0x12 [ 91.108880] [<c1195ccf>] evm_verify_hmac+0xdd/0x149 [ 91.114468] [<c102cac7>] ? vprintk_emit+0x391/0x3cf [ 91.120042] [<c1195dcd>] evm_verifyxattr+0x53/0x63 [ 91.125520] [<c11958fc>] ima_appraise_measurement+0xaa/0x1b9 [ 91.131970] [<c1194b39>] process_measurement+0x13d/0x182 [ 91.138021] [<c1194ce8>] ima_file_check+0x16a/0x182 [ 91.143597] [<c10e2962>] do_last.clone.26+0x7c1/0x90e [ 91.149355] [<c10e0145>] ? inode_permission+0x3f/0x41 [ 91.155123] [<c10e01ac>] ? link_path_walk+0x65/0x670 [ 91.160793] [<c10e2b44>] path_openat.clone.27+0x95/0x352 [ 91.166852] [<c1070107>] ? trace_hardirqs_off+0xb/0xd [ 91.172619] [<c10e3022>] do_filp_open+0x21/0x5d [ 91.177805] [<c10edd68>] ? __alloc_fd+0x178/0x183 [ 91.183185] [<c10d769c>] do_sys_open+0x104/0x17d [ 91.188468] [<c10d7736>] sys_open+0x21/0x29 [ 91.193265] [<c1422ffe>] sysenter_do_call+0x12/0x36 The kernel I'm using is 3.8.0 Thanks, Marek Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk Registergericht: Muenchen HRB 47456 Ust.-IdNr./VAT Registration No.: DE129385895 Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052 |
|
From: Dmitry K. <d.k...@sa...> - 2014-02-07 12:24:59
|
Hi Marek, Can you please check your kernel configuration file if CRYPTO_HMAC and CRYPTO_SHA1 are enabled there? It should not call request module... - Dmitry On 07/02/14 14:09, Lipinski, MarekX wrote: > Hi, > > I'm trying to enable IMA/EVM on my box. I'm experiencing problems in the following situation: > System is booted with rootflags=i_version ima_appraise_tcb ima_appraise=fix evm=fix. > EVM is being enabled at the very begining of the booting. Init script (passed to the kernel) mounts /sys, /proc, /dev, loads the emv-key file and starts the EVM by echoing "1" into /sys/kernel/security/evm. Untill now everything is ok and I'm getting 'EVM: initialized' message. > > After that running any other executable causes the deadlock. It looks as if before execution EVM tries to calculate the HMAC. init_desc function is being called, which tries to load hmac(sha1) algorithm. Crypto API calls request_module, which tries to run /sbin/modprobe. Before executing modprobe executable is being verified To have correct EVM HMAC. This again causes the init_desc to be executed and hang on the mutex_lock. > > Can anyone tell me what I'm doing wrong? > > The only workaround that comes to my mind is to force evms init_desc to be run before evm is enabled so the algorithm is loaded and any subsequent call will not require requesting module. > > Kernel debug message: > > [ 90.993569] INFO: task modprobe:110 blocked for more than 30 seconds. > [ 91.000801] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > [ 91.009576] modprobe D 00000000 0 110 109 0x00000000 > [ 91.016754] f3051cac 00000046 00000249 00000000 f30783b0 c182a200 c16e3000 c182a200 > [ 91.025632] 2bdcc63b 00000008 2ae91efb 00000008 f30783b0 f3051c64 00000006 00000019 > [ 91.034514] 00000001 00000000 c11be254 f30783b0 c192b8b4 00000040 f30783b0 00000001 > [ 91.043371] Call Trace: > [ 91.046137] [<c11be254>] ? trace_hardirqs_on_thunk+0xc/0x10 > [ 91.052491] [<c10722c3>] ? mark_held_locks+0xae/0xd0 > [ 91.058163] [<c14201cb>] ? mutex_lock_nested+0x152/0x2a2 > [ 91.064288] [<c1421517>] schedule+0x51/0x53 > [ 91.069086] [<c1421712>] schedule_preempt_disabled+0x12/0x1e > [ 91.075534] [<c14201e7>] mutex_lock_nested+0x16e/0x2a2 > [ 91.081399] [<c1195f7e>] ? init_desc+0x52/0x177 > [ 91.086585] [<c1195f7e>] init_desc+0x52/0x177 > [ 91.091576] [<c1196144>] evm_calc_hmac_or_hash+0x47/0xed > [ 91.097636] [<c10f3404>] ? vfs_getxattr_alloc+0x8d/0xa9 > [ 91.103598] [<c11961fa>] evm_calc_hmac+0x10/0x12 > [ 91.108880] [<c1195ccf>] evm_verify_hmac+0xdd/0x149 > [ 91.114468] [<c102cac7>] ? vprintk_emit+0x391/0x3cf > [ 91.120042] [<c1195dcd>] evm_verifyxattr+0x53/0x63 > [ 91.125520] [<c11958fc>] ima_appraise_measurement+0xaa/0x1b9 > [ 91.131970] [<c1194b39>] process_measurement+0x13d/0x182 > [ 91.138021] [<c1194ce8>] ima_file_check+0x16a/0x182 > [ 91.143597] [<c10e2962>] do_last.clone.26+0x7c1/0x90e > [ 91.149355] [<c10e0145>] ? inode_permission+0x3f/0x41 > [ 91.155123] [<c10e01ac>] ? link_path_walk+0x65/0x670 > [ 91.160793] [<c10e2b44>] path_openat.clone.27+0x95/0x352 > [ 91.166852] [<c1070107>] ? trace_hardirqs_off+0xb/0xd > [ 91.172619] [<c10e3022>] do_filp_open+0x21/0x5d > [ 91.177805] [<c10edd68>] ? __alloc_fd+0x178/0x183 > [ 91.183185] [<c10d769c>] do_sys_open+0x104/0x17d > [ 91.188468] [<c10d7736>] sys_open+0x21/0x29 > [ 91.193265] [<c1422ffe>] sysenter_do_call+0x12/0x36 > > > The kernel I'm using is 3.8.0 > > Thanks, > Marek > Intel GmbH > Dornacher Strasse 1 > 85622 Feldkirchen/Muenchen, Deutschland > Sitz der Gesellschaft: Feldkirchen bei Muenchen > Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk > Registergericht: Muenchen HRB 47456 > Ust.-IdNr./VAT Registration No.: DE129385895 > Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052 > > > ------------------------------------------------------------------------------ > Managing the Performance of Cloud-Based Applications > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. > Read the Whitepaper. > http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk > _______________________________________________ > Linux-ima-user mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux-ima-user > |
|
From: Lipinski, M. <mar...@in...> - 2014-02-07 12:09:49
|
Hi, I'm trying to enable IMA/EVM on my box. I'm experiencing problems in the following situation: System is booted with rootflags=i_version ima_appraise_tcb ima_appraise=fix evm=fix. EVM is being enabled at the very begining of the booting. Init script (passed to the kernel) mounts /sys, /proc, /dev, loads the emv-key file and starts the EVM by echoing "1" into /sys/kernel/security/evm. Untill now everything is ok and I'm getting 'EVM: initialized' message. After that running any other executable causes the deadlock. It looks as if before execution EVM tries to calculate the HMAC. init_desc function is being called, which tries to load hmac(sha1) algorithm. Crypto API calls request_module, which tries to run /sbin/modprobe. Before executing modprobe executable is being verified To have correct EVM HMAC. This again causes the init_desc to be executed and hang on the mutex_lock. Can anyone tell me what I'm doing wrong? The only workaround that comes to my mind is to force evms init_desc to be run before evm is enabled so the algorithm is loaded and any subsequent call will not require requesting module. Kernel debug message: [ 90.993569] INFO: task modprobe:110 blocked for more than 30 seconds. [ 91.000801] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 91.009576] modprobe D 00000000 0 110 109 0x00000000 [ 91.016754] f3051cac 00000046 00000249 00000000 f30783b0 c182a200 c16e3000 c182a200 [ 91.025632] 2bdcc63b 00000008 2ae91efb 00000008 f30783b0 f3051c64 00000006 00000019 [ 91.034514] 00000001 00000000 c11be254 f30783b0 c192b8b4 00000040 f30783b0 00000001 [ 91.043371] Call Trace: [ 91.046137] [<c11be254>] ? trace_hardirqs_on_thunk+0xc/0x10 [ 91.052491] [<c10722c3>] ? mark_held_locks+0xae/0xd0 [ 91.058163] [<c14201cb>] ? mutex_lock_nested+0x152/0x2a2 [ 91.064288] [<c1421517>] schedule+0x51/0x53 [ 91.069086] [<c1421712>] schedule_preempt_disabled+0x12/0x1e [ 91.075534] [<c14201e7>] mutex_lock_nested+0x16e/0x2a2 [ 91.081399] [<c1195f7e>] ? init_desc+0x52/0x177 [ 91.086585] [<c1195f7e>] init_desc+0x52/0x177 [ 91.091576] [<c1196144>] evm_calc_hmac_or_hash+0x47/0xed [ 91.097636] [<c10f3404>] ? vfs_getxattr_alloc+0x8d/0xa9 [ 91.103598] [<c11961fa>] evm_calc_hmac+0x10/0x12 [ 91.108880] [<c1195ccf>] evm_verify_hmac+0xdd/0x149 [ 91.114468] [<c102cac7>] ? vprintk_emit+0x391/0x3cf [ 91.120042] [<c1195dcd>] evm_verifyxattr+0x53/0x63 [ 91.125520] [<c11958fc>] ima_appraise_measurement+0xaa/0x1b9 [ 91.131970] [<c1194b39>] process_measurement+0x13d/0x182 [ 91.138021] [<c1194ce8>] ima_file_check+0x16a/0x182 [ 91.143597] [<c10e2962>] do_last.clone.26+0x7c1/0x90e [ 91.149355] [<c10e0145>] ? inode_permission+0x3f/0x41 [ 91.155123] [<c10e01ac>] ? link_path_walk+0x65/0x670 [ 91.160793] [<c10e2b44>] path_openat.clone.27+0x95/0x352 [ 91.166852] [<c1070107>] ? trace_hardirqs_off+0xb/0xd [ 91.172619] [<c10e3022>] do_filp_open+0x21/0x5d [ 91.177805] [<c10edd68>] ? __alloc_fd+0x178/0x183 [ 91.183185] [<c10d769c>] do_sys_open+0x104/0x17d [ 91.188468] [<c10d7736>] sys_open+0x21/0x29 [ 91.193265] [<c1422ffe>] sysenter_do_call+0x12/0x36 The kernel I'm using is 3.8.0 Thanks, Marek Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk Registergericht: Muenchen HRB 47456 Ust.-IdNr./VAT Registration No.: DE129385895 Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052 |
|
From: Tamleek A. <tam...@gm...> - 2014-01-17 04:48:50
|
Hi, I guess the IMA start extending PCR 10 with ''boot-aggregate'' that already contains the previous measurements i.e. BIOS->TrustedGRUB etc. so the chain gets completed. Regards, Tamleek Ali On Thu, Jan 16, 2014 at 9:41 PM, Mimi Zohar <zo...@li...>wrote: > On Thu, 2014-01-16 at 15:48 +0100, hassan Ahamad wrote: > > TrustedGRUB is measuring the Linux kernel (see: > > http://projects.sirrix.com/trac/trustedgrub/wiki/Documentation). Thus > the > > chain-of-trust, I was talking about (BIOS->TrustedGRUB->Linux-Kernel > (with > > IMA)->applications), is complete. > > > > I am curious as IMA is only extending PCR 10. Which piece of code is > > extending PCR 0 - 7? > > <securityfs>/tpm0/binary_bios_measurements contains the measurements > that extend the PCRs 0 - 7. The IMA LTP testsuite contains examples how > to verify PCRs and the boot-aggregate. > > Mimi > > > > ------------------------------------------------------------------------------ > CenturyLink Cloud: The Leader in Enterprise Cloud Services. > Learn Why More Businesses Are Choosing CenturyLink Cloud For > Critical Workloads, Development Environments & Everything In Between. > Get a Quote or Start a Free Trial Today. > > http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk > _______________________________________________ > Linux-ima-user mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux-ima-user > |
|
From: Mimi Z. <zo...@li...> - 2014-01-16 16:41:51
|
On Thu, 2014-01-16 at 15:48 +0100, hassan Ahamad wrote: > TrustedGRUB is measuring the Linux kernel (see: > http://projects.sirrix.com/trac/trustedgrub/wiki/Documentation). Thus the > chain-of-trust, I was talking about (BIOS->TrustedGRUB->Linux-Kernel (with > IMA)->applications), is complete. > > I am curious as IMA is only extending PCR 10. Which piece of code is > extending PCR 0 - 7? <securityfs>/tpm0/binary_bios_measurements contains the measurements that extend the PCRs 0 - 7. The IMA LTP testsuite contains examples how to verify PCRs and the boot-aggregate. Mimi |
|
From: hassan A. <has...@gm...> - 2014-01-16 14:48:55
|
TrustedGRUB is measuring the Linux kernel (see: http://projects.sirrix.com/trac/trustedgrub/wiki/Documentation). Thus the chain-of-trust, I was talking about (BIOS->TrustedGRUB->Linux-Kernel (with IMA)->applications), is complete. I am curious as IMA is only extending PCR 10. Which piece of code is extending PCR 0 - 7? On Tue, Jan 14, 2014 at 3:43 PM, Mimi Zohar <zo...@li...>wrote: > On Tue, 2014-01-14 at 13:40 +0100, hassan Ahamad wrote: > > I somehow made IMA work on Ubuntu by compiling the kernel. However I can > > see the measurements from IMA by using this command "sudo cat > > /sys/kernel/security/ima/ascii_runtime_measurements", But I haven't > > installed trusted-grub, this again confuses me that how the chain of > trust > > will establish now and are the measurements trusted in this case. > > You're absolutely correct, something needs to measure the kernel and > initramfs for there to be a measurement chain of trust. The problem is > that trusted grub has been around for years, but has not been upstreamed > for, lets leave it as, "political" reasons. The community has moved on > to secure-boot, using grub2. For secure boot, a hash of the kernel > image has to be calculated. The question is whether grub2 adds the > measurement to a PCR. > > > My PCR values are as follows, > > A hash of the PCR 0 - 7 measurements are included in the IMA measurement > list as the first entry. > > thanks, > > Mimi > > |
|
From: Mimi Z. <zo...@li...> - 2014-01-15 15:07:59
|
On Wed, 2014-01-15 at 19:42 +0530, Rishi Gandhi wrote: > I have used initial patches of IMA to make it available in linux kernel > 2.6.18. > And in kernel code i changed it to print full path of bprm filename and the > measurement value is as below : > 10 37dd365996374e967a6568854166722750e368e0 ima* 9eb30c85c49cc1a4fa85976c707769c65d473800 /init* > 10 2f6264d10a16e4bf553d5754bb53c29226d5de24 ima* eaaf413b06cd215b1b1f85c9ccb3d31c23fefa88 /init* >10 fd218befcddfa26dcadcb9b6e5a1efc1d69f1293 ima* 74772a232661bb3ecb37d403416c848bcc170949 /sbin/init* Understanding the source of the measurements has been a problem. The measurements are a fixed format, containing a sha1 hash of the file and the filename. Linux-3.13, when released, will have support for a new, more flexible template architecture, which will allow additional file metadata to be included. linux-3.7 added the option of audit logging the measurements with additional file metadata. Instead of backporting all of it, you might try just calling ima_audit_measurement() directly for each measurement. thanks, Mimi |
|
From: Rishi G. <ris...@gm...> - 2014-01-15 14:12:43
|
I have used initial patches of IMA to make it available in linux kernel 2.6.18. And in kernel code i changed it to print full path of bprm filename and the measurement value is as below : 10 428d402c6e3520b6b33e567250922b1c2410c9b2 ima ffffffffffffffffffffffffffffffffffffffff boot_aggregate 10 37dd365996374e967a6568854166722750e368e0 ima* 9eb30c85c49cc1a4fa85976c707769c65d473800 /init* 10 2f6264d10a16e4bf553d5754bb53c29226d5de24 ima *eaaf413b06cd215b1b1f85c9ccb3d31c23fefa88 /init* 10 c4f74cd855200656442117bd5ae88e201f89a7f4 ima 4615536ae520d3be32f6904e71c48f938be5d1d1 /bin/insmod 10 78dc232efd5f227d38ed86b3d839601e818a13a2 ima 4f5205e3a758583268ed2de04800288de2f86b18 /bin/lvm 10 fd218befcddfa26dcadcb9b6e5a1efc1d69f1293 ima *74772a232661bb3ecb37d403416c848bcc170949 /sbin/init* 10 5f13e006f73f2fdfa4554fefd635caaa920bc6d2 ima 863e9feac2842ba6e3a3b894e863938d80638ca0 ld-2.5.so 10 750b8efa2e17ae24020c6db65bc465bd5fc57371 ima 447741e2da357845aea29481e5b602cf6c46a42d libsepol.so.1 10 5c3cb54b440602b12e34ea3228aa9aae909ec53c ima f742ff7b66fe9cfd16ded1222445c01af9eecc38 libselinux.so.1 10 163f8efc92fa077172d4d64c56b4f0b74d10ac49 ima 0f71a1a4c6fd6d475f2c540ae7cb375c0365dbb5 libc-2.5.so 10 2b2f53a6a52537316c7891ea1a688620d4516bc6 ima 8132e511b539305a307e35b33b6f393b0e4eb1cc libdl-2.5.so 10 22a299ef7d242ae4c44c24903ad5e5bf743d6a9b ima *5e3548bcf2513ce5493014b7ef258dd172e2c396 /etc/rc.d/rc.sysinit* 10 ea5ae5167282ff3b197437973f78ec64ec7f272d ima *105c6a1c05b394710a63db7e9d277cbdbe54ae76 /etc/rc.d/rc.sysinit* 10 d9d4fd02a5d9a04f6e403301754603b4cfaf02c9 ima 8ff97d65bcf5a98a68ed3141f9c93e55e607309f libtermcap.so.2.0.8 10 00fc4800026a38cf49e72e3366b219502208ba01 ima b0f481235f3ff30d474a4c549dc8e4b9fee47570 libnss_files-2.5.so 10 c067cb7e38c37a9656d5459f5510475adebe944a ima 9d1ec152eae342482b5266465d20f7ebab1326e2 /bin/hostname 10 ddb673075a27543246005469e7813cf159463d0b ima 3caf6dc36756d135a9fa95f61610eaba0eb7e0b4 /bin/uname 10 b8478267564da72236a4eda4338b585cb2907156 ima d2757b64dd0ff12211986d1ca53baafccba1a977 /bin/mount as you can see above in measurement list there are three entries of 'init' namely /init, /init and /sbin/init. All the three entries different hash values. As i had earlier said i found first and third entries of init matched with hash values of initramfs(decompressed initramfs i.e initrd) and /sbin/init. I am unable to figure out from where second entry of /init is coming having different measurement than of rest two init entries. Same is the case with two entries of /etc/rc.d/rc.sysinit out of which first entry's hash value matched with existing file in filesystem. please clarify about second etry of init and rc.sysinit. Thanks On Sun, Jan 12, 2014 at 8:56 PM, Mimi Zohar <zo...@li...>wrote: > On Sat, 2014-01-11 at 13:30 +0530, Rishi Gandhi wrote: > > Hi, > > I am using IMA in linux kernel 2.6.18 having red-hat el5. > > In my measurement list I am getting three entries in measurement list > > (asscii_measurement list). > > > > The three entries are of > > * /init > > * /init > > * /sbin/init > > out of which first entry of /init is of initramfs and third entry is of > > /sbin/init when compared with hash value. I am not able to figure out how > > second /init entry is coming in my measurement list. > > > > and the same case is with rc.sysinit in /etc/rc.sysinit > > > > Please clarify from where second entry of /init and /etc/rc/sysinit is > > coming and what it signifies? and where can i find those in source code. > > When IMA was originally upstreamed, there were two /init measurements. > One was from the initramfs, while the other was from the real root. > Subsequent patches used the bprm filename, not the short name. My > guess, without looking at which patches were back ported, would be that > the second /init was done at file_check on the real root. The > '/sbin/init' measurement was done at bprm_check. Are file hash > measurements the same for the second and last entries? > > thanks, > > Mimi > > |
|
From: Rishi G. <ris...@gm...> - 2014-01-15 14:11:11
|
Hi, I am using IMA in linux kernel 2.6.18 having red-hat el5. In my measurement list I am getting three entries in measurement list (asscii_measurement list). The three entries are of * /init * /init * /sbin/init out of which first entry of /init is of initramfs and third entry is of /sbin/init when compared with hash value. I am not able to figure out how second /init entry is coming in my measurement list. and the same case is with rc.sysinit in /etc/rc.sysinit Please clarify from where second entry of /init and /etc/rc/sysinit is coming and what it signifies? and where can i find those in source code. Thanks Rishi |
|
From: Vladimir 'φ-coder/p. S. <ph...@gm...> - 2014-01-14 20:35:45
|
On 14.01.2014 21:21, Mimi Zohar wrote: > On Tue, 2014-01-14 at 19:30 +0100, Vladimir 'φ-coder/phcoder' Serbinenko > wrote: >> On 14.01.2014 16:59, Peter Jones wrote: >>> PCR, as well as having grub2 do so for its config, the kernel, and any >>> initramfses to be loaded. Doing so on a UEFI machine isn't a particularly >>> difficult change to grub2 - but you may face the same political >>> problems. It's probably worth asking Vladimir Serbinenko, who I've >>> Cced, as he's the upstream maintainer of grub2. > >> GRUB2 has RSA/DSA gnupg signature checking. Currently in mainstream it >> supports only detached GPG signatures but I have a branch where I work >> on PE signatures (phcoder/file_types). For me we could use either. In >> the same branch I also work on implementing partial checks (check only >> files needed to satisfy EFI stuff). This approach gives similar (if not >> better) security gurantees (unless rollback is a problem, usually it's >> not and preventing it prevents normal activity as backup restore as >> well) but has no political problems. The only part which may be >> politically problematic is enforcing this check depending on EFI >> variables but this would be a tiny patch remaining. Another advantage of >> this approach is easy integration with coreboot (just use GRUB2 as >> payload) I didn't finish this approach yet. Missing parts are file types >> (I still wait for answer from Peter Jones as to which files needs to be >> checked) and PE signatures (WIP). > > Thanks for responding! In order to verify the signatures, you're > already calculating file hashes. Would it be possible to also extend > the TPM with these hashes and add them to the measurement list? > It's difficult to see which modules GRUB loads and in which order. I'd prefer using a key to tie together kernel and modules. This way whole GRUB core+modules+signed kernel could be single block for TPM. GRUB is part of GNU. As FSF project whether it has any TPM depends on FSF politics. I'm not up to a flamewar of how and why, I'm just stating the fact that as long as FSF has anti-TPM policy any admission of TPM-related code needs approval by FSF (approval on generic functionality, not on details) and I'd recommend taking it to them. I'm open to extending signatures with additional features but not a single TPM hash write could occur in upstream GRUB without FSF approval. Neverthelss I'd like to be kept in the loop about any branch that would use TPM. > thanks, > > Mimi > > |
32 messages has been excluded from this view by a project administrator.
