Messages in this thread | | | Date | Fri, 30 Dec 2011 18:51:37 -0500 | From | KOSAKI Motohiro <> | Subject | Re: [patch 1/4] Add routine for generating an ID for kernel pointer |
| |
(12/30/11 3:48 PM), Cyrill Gorcunov wrote: > On Fri, Dec 30, 2011 at 03:31:32PM -0500, KOSAKI Motohiro wrote: >> (12/30/11 2:36 AM), Cyrill Gorcunov wrote: >>> On Fri, Dec 30, 2011 at 11:23:09AM +1100, Herbert Xu wrote: >>>> On Thu, Dec 29, 2011 at 08:24:53PM +0400, Cyrill Gorcunov wrote: >>>>> >>>>> Probably I've had to crypto_alloc_hash earlier and simply keep a reference >>>>> to algo but since I'm not sure if looking for modules in late-init-call >>>>> is good idea. >>>> >>>> Right, the allocation needs to occur in a sleepable context. >>>> >>>> If you're just hashing something small and have no need for >>>> hardware acceleration then lib/sha1.c is fine. >>>> >>> >>> Hi, yeah, it's just one message block hashing so I've switched >>> to lib/sha1.c. Herbert, I'm more interested in security analysis >>> -- would the sha1(msg), where the 'msg' is the kernel pointer >>> XOR'ed with random value and expanded to the 512 bits would be >>> safe enough for export to unprivilege users? >> >> Even if now we don't know an attacking way of sha1 reverse hashing, >> we may discover within 10 years. Many secure messages lost from >> hardware speedup and new algorithm attack. so, nobody can say it's >> abi safe. >> > > Yes, I know. But there is a big difference between direct hash crack and > indirect crack caused by limited space of data used for such hash. That's > the reason why random cookie was used and xor production was expanded to > the whole message block. > >> And, if you don't use perfect hash, you may have a hash collision >> risk. What's happen if different pointer makes same ID? > > Well, strictly speaking this is pretty bad case for me. Of course this > wont lead to catastrophic results for user-space application I think > but definitely I would prefer to not have collisions here. > > Guys, this become more and more complex, finally I fear someone > propose to do ideal hashing run-time ;) Maybe we can step back and > live with root-only and plain pointers here? I'm not sure who else > might need such facility except us, and if once there will be a candidate > -- we could take a look on hashing again and provide safe hashes there. No?
But recently kernel security fashion are, we don't expose a kernel pointer at all even though the file is root only. I'm not sure how much effective such fashion. but you seems run opposite way.
I doubt user land can implement good comparison way. Why you gave up Andrew's sys_are_these_files_the_same() idea?
| |