Re: [PATCH 4/4] x86/ima: define arch_get_ima_policy() for x86
Hi Eric, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on integrity/next-integrity] [also build test WARNING on next-20180727] [cannot apply to v4.18-rc6] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Eric-Richter/ima-add-support-for-arch-specific-policies/20180728-072442 base: https://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity.git next-integrity smatch warnings: security/integrity/ima/ima_policy.c:522 ima_init_arch_policy() error: potential null dereference 'arch_policy_entry'. (kcalloc returns null) vim +/arch_policy_entry +522 security/integrity/ima/ima_policy.c b4c0791e Nayna Jain 2018-07-25 484 b4c0791e Nayna Jain 2018-07-25 485 /* b4c0791e Nayna Jain 2018-07-25 486 * ima_init_arch_policy - convert arch policy strings to rules b4c0791e Nayna Jain 2018-07-25 487 * b4c0791e Nayna Jain 2018-07-25 488 * Return number of arch specific rules. b4c0791e Nayna Jain 2018-07-25 489 */ b4c0791e Nayna Jain 2018-07-25 490 static int __init ima_init_arch_policy(void) b4c0791e Nayna Jain 2018-07-25 491 { b4c0791e Nayna Jain 2018-07-25 492 const char * const *arch_rules; b4c0791e Nayna Jain 2018-07-25 493 const char * const *rules; b4c0791e Nayna Jain 2018-07-25 494 int arch_entries = 0; b4c0791e Nayna Jain 2018-07-25 495 int i = 0; b4c0791e Nayna Jain 2018-07-25 496 b4c0791e Nayna Jain 2018-07-25 497 arch_rules = arch_get_ima_policy(); b4c0791e Nayna Jain 2018-07-25 498 if (!arch_rules) { b4c0791e Nayna Jain 2018-07-25 499 pr_info("No architecture policy rules.\n"); b4c0791e Nayna Jain 2018-07-25 500 return arch_entries; b4c0791e Nayna Jain 2018-07-25 501 } b4c0791e Nayna Jain 2018-07-25 502 b4c0791e Nayna Jain 2018-07-25 503 /* Get number of rules */ b4c0791e Nayna Jain 2018-07-25 504 for (rules = arch_rules; *rules != NULL; rules++) b4c0791e Nayna Jain 2018-07-25 505 arch_entries++; b4c0791e Nayna Jain 2018-07-25 506 b4c0791e Nayna Jain 2018-07-25 507 arch_policy_rules = kcalloc(arch_entries + 1, b4c0791e Nayna Jain 2018-07-25 508 sizeof(*arch_policy_rules), GFP_KERNEL); b4c0791e Nayna Jain 2018-07-25 509 if (!arch_policy_rules) b4c0791e Nayna Jain 2018-07-25 510 return 0; b4c0791e Nayna Jain 2018-07-25 511 b4c0791e Nayna Jain 2018-07-25 512 arch_policy_entry = kcalloc(arch_entries + 1, b4c0791e Nayna Jain 2018-07-25 513 sizeof(*arch_policy_entry), GFP_KERNEL); b4c0791e Nayna Jain 2018-07-25 514 b4c0791e Nayna Jain 2018-07-25 515 /* Convert arch policy string rules to struct ima_rule_entry format */ b4c0791e Nayna Jain 2018-07-25 516 for (rules = arch_rules, i = 0; *rules != NULL; rules++) { b4c0791e Nayna Jain 2018-07-25 517 char rule[255]; b4c0791e Nayna Jain 2018-07-25 518 int result; b4c0791e Nayna Jain 2018-07-25 519 b4c0791e Nayna Jain 2018-07-25 520 result = strlcpy(rule, *rules, sizeof(rule)); b4c0791e Nayna Jain 2018-07-25 521 b4c0791e Nayna Jain 2018-07-25 @522 INIT_LIST_HEAD(&arch_policy_entry[i].list); b4c0791e Nayna Jain 2018-07-25 523 result = ima_parse_rule(rule, &arch_policy_entry[i]); b4c0791e Nayna Jain 2018-07-25 524 if (result) { b4c0791e Nayna Jain 2018-07-25 525 pr_warn("Skipping unknown architecture policy rule: %s\n", rule); b4c0791e Nayna Jain 2018-07-25 526 memset(&arch_policy_entry[i], 0, b4c0791e Nayna Jain 2018-07-25 527 sizeof(*arch_policy_entry)); b4c0791e Nayna Jain 2018-07-25 528 continue; b4c0791e Nayna Jain 2018-07-25 529 } b4c0791e Nayna Jain 2018-07-25 530 arch_policy_rules[i] = &arch_policy_entry[i]; b4c0791e Nayna Jain 2018-07-25 531 i++; b4c0791e Nayna Jain 2018-07-25 532 } b4c0791e Nayna Jain 2018-07-25 533 return i; b4c0791e Nayna Jain 2018-07-25 534 } b4c0791e Nayna Jain 2018-07-25 535 :: The code at line 522 was first introduced by commit :: b4c0791e0facd968a3e0502a8a544390025a9a38 ima: add support for arch specific policies :: TO: Nayna Jain :: CC: 0day robot --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/18] xfrm: Add compat layer
On Fri, 2018-07-27 at 09:48 -0700, Nathan Harold wrote: > We (Android) are very interested in removing the restriction for 32- > bit userspace processes accessing xfrm netlink on 64-bit kernels. > IPsec support is required to pass Android conformance tests, and any > manufacturer wishing to ship 32-bit userspace with a recent kernel > needs out-of-tree changes (removing the compat_task check) to do so. Glad to hear - that justify my attempts more :) > That said, it’s not difficult to work around alignment issues > directly in userspace, so maybe we could just remove the check and > make this the caller's responsibility? Here’s an example of the > workaround currently in the Android tree: > https://android.googlesource.com/platform/system/netd/+/refs/heads/ma > ster/server/XfrmController.h#257 We've kinda same workarounds in our userspace.. But I don't think reverting the check makes much sense - it'll make broken compat ABI in stone. If you're fine with disgraceful hacks and just want to get rid of additional non-mainstream patch - you can make 64-bit syscalls from 32- bit task (hint: examples in x86 selftests). > We could also employ a (relatively simple) solution such as the one > above in the uapi XFRM header itself, though it would require a > caller to declare the target kernel ABI at compile time. Maybe that’s > not unthinkable for an uncommon case? Well, I think, I'll rework my patches set according to critics and separate compat xfrm layer. I've already a selftest to check that 32/64 bit xfrm works - so the most time-taking part is done. So, if you'll wait a week or two - you may help me to justify acception of mainstreaming those patches. > On Fri, Jul 27, 2018 at 7:51 AM, Dmitry Safonov > wrote: > > On Fri, 2018-07-27 at 16:19 +0200, Florian Westphal wrote: > > > Dmitry Safonov wrote: > > > > 1. It will double copy netlink messages, making it O(n) instead > > of > > > > O(1), where n - is number of bind()s.. Probably we don't care > > much. > > > > > > About those bind() patches, I don't understand why they are > > needed. > > > > > > Why can't you just add the compat skb to the native skb when > > doing > > > the multicast call? > > > > > > skb_shinfo(skb)->frag_list = compat_skb; > > > xfrm_nlmsg_multicast(net, skb, 0, ... > > > > Oh yeah, sorry, I think I misread the patch - will try to add > > compat > > skb in the multicast call. > > -- Thanks, Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/18] xfrm: Add compat layer
From: Dmitry Safonov Date: Sat, 28 Jul 2018 17:26:55 +0100 > Well, I think, I'll rework my patches set according to critics and > separate compat xfrm layer. I've already a selftest to check that 32/64 > bit xfrm works - so the most time-taking part is done. The way you've done the compat structures using __packed is only going to work on x86, just FYI. The "32-bit alignment for 64-bit objects" thing x86 has is very much not universal amongst ABIs having 32-bit and 64-bit variants. -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html