Menu
▾
▴
Re: [Linux-ima-user] Deadlock after enabling EVM in fix mode
|
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 > > |