Re: [Linux-ima-devel] [PATCH v2 4/7] ima: measure and appraise kexec image and initramfs
Hi, Mimi On 12/28/15 at 07:51am, Mimi Zohar wrote: > On Mon, 2015-12-28 at 10:08 +0800, Dave Young wrote: > > On 12/25/15 at 09:45am, Mimi Zohar wrote: > > > IMA calculates the file hash, in this case, based on the buffer > > > contents. The hash is calculated once and used for both measurement > > > and appraisal. If the file integrity appraisal fails (eg. hash > > > comparison or signature failure), IMA prevents the kexec files from > > > being used. > > > > > > > Ok, thanks for the explanatioin. But I have another question, why do we > > need a special hook for KEXEC? Shouldn't all files use same way to do the > > measurement and appraisal? > > "By all files" are you referring to all files read by the kernel or all > files opened, executed or mmapped by the system? Hmm, I means any kind of files read by the kernel. > > Currently IMA allocates a page sized buffer, reads a file a page chunk > at a time calculating the file hash as it does so, and then frees the > buffer before returning to the caller. This method of calculating the > file hash is used for measuring and appraising files opened > (FILE_CHECK), executed (BPRM_CHECK) or mmapped (MMAP_CHECK) by the > system. > > This patch set addresses files being read by kernel. A single new > generic hook named ima_hash_and_process_file() is defined to not only > measure and appraise the kexec image and initramfs, but firmware and the > IMA policy. As we identify other places that the kernel is reading > files, this hook would be called in those places as well. What I can not understand is why IMA need know the caller information and why cann't introduce a generic interface. kexec and firmware and other caller all read files, so a common file based interface should be better? Thanks Dave ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH 2/2] kexec: Provide arch_kexec_protect(unprotect)_crashkres()
On 12/28/2015 at 08:14 PM, Minfei Huang wrote:
> On 12/28/15 at 02:32pm, Xunlei Pang wrote:
>> On 12/24/2015 at 02:44 PM, Xunlei Pang wrote:
>>> +static void kexec_mark_crashkres(bool protect)
>>> +{
>>> + unsigned long control;
>>> +
>>> + kexec_mark_range(crashk_low_res.start, crashk_low_res.end,
>>> protect);
>>> +
>>> + /* Don't touch the control code page used in crash_kexec().*/
>>> + control =
>>> PFN_PHYS(page_to_pfn(kexec_crash_image->control_code_page));
>>> + /* Control code page is located in the 2nd page. */
>>> + control = control + PAGE_SIZE;
Though it works because the control code is less than 1 page, but use the
macro
of KEXEC_CONTROL_PAGE_SIZE looks better..
>> The 1st page is pagetable, control code page locates at the 2nd page.
>> The following kexec_mark_range() wants to mark ro from crashk_res.start
>> to the 1st page(included), so here we must use PAGE_SIZE.
>>
>>> + kexec_mark_range(crashk_res.start, control - 1, protect);
>>> + kexec_mark_range(control + PAGE_SIZE, crashk_res.end, protect);
>> X86 kexec will copy the page while kexecing, could you check if we can
>> move
>> that copying to earliyer while kexec loading, maybe
>> machine_kexec_prepare so
>> that we can make a arch-independent implementation.
> For some arch, may use huge tlb directly to do the kernel mapping,
> in such cases, we can't implement this function. So I think it should
> be arch-dependent.
Ok, that's fine.
>>> At least moving the x86 control-copying code into arch-related
>>> machine_kexec_prepare() should work, and this can omit the
>>> special treatment of the control code page.
>> The "relocate_kernel" routine in "relocate_kernel_64.S" will use it as
>> a temp storage "for jumping back"(as its comment), so we can't mark
>> it readonly.
> kexec will copy the relocate_kernel binary to control_code_page in
> function machine_kexec. This is a major reason to set the region
> control_code_page to control_code_page + PAGE_SIZE with mode read/write.
Yes, I mean after avoiding this copy by moving the x86 control-copying
code into arch-related machine_kexec_prepare(), we still can't mark it
readonly because of its temp storage role.
Of course we can still do that by setting its kernel pte to rwx and do a
local tlb invalidation when crash_kexec(), but I think we can simply leave
that alone, since its content is meaningless before crash happens where
the code is copied into it. Unless you want to capture the wrong kernel
operations that only write to this reserved page.
Regards,
Xunlei
>
> Thanks
> Minfei
>
> ___
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [Linux-ima-devel] [PATCH v2 4/7] ima: measure and appraise kexec image and initramfs
On Tue, 2015-12-29 at 16:21 +0800, Dave Young wrote: > Hi, Mimi > > On 12/28/15 at 07:51am, Mimi Zohar wrote: > > On Mon, 2015-12-28 at 10:08 +0800, Dave Young wrote: > > > On 12/25/15 at 09:45am, Mimi Zohar wrote: > > > > IMA calculates the file hash, in this case, based on the buffer > > > > contents. The hash is calculated once and used for both measurement > > > > and appraisal. If the file integrity appraisal fails (eg. hash > > > > comparison or signature failure), IMA prevents the kexec files from > > > > being used. > > > > > > > > > > Ok, thanks for the explanatioin. But I have another question, why do we > > > need a special hook for KEXEC? Shouldn't all files use same way to do the > > > measurement and appraisal? > > > > "By all files" are you referring to all files read by the kernel or all > > files opened, executed or mmapped by the system? > > Hmm, I means any kind of files read by the kernel. > > > > > Currently IMA allocates a page sized buffer, reads a file a page chunk > > at a time calculating the file hash as it does so, and then frees the > > buffer before returning to the caller. This method of calculating the > > file hash is used for measuring and appraising files opened > > (FILE_CHECK), executed (BPRM_CHECK) or mmapped (MMAP_CHECK) by the > > system. > > > > This patch set addresses files being read by kernel. A single new > > generic hook named ima_hash_and_process_file() is defined to not only > > measure and appraise the kexec image and initramfs, but firmware and the > > IMA policy. As we identify other places that the kernel is reading > > files, this hook would be called in those places as well. > > What I can not understand is why IMA need know the caller information and > why cann't introduce a generic interface. kexec and firmware and other > caller all read files, so a common file based interface should be better? The next patch set will define a common function for reading files by the kernel. Luis set up a wiki http://kernelnewbies.org/KernelProjects/common-kernel-loader with some details. This patch set defines a generic interface for measuring and appraising files being read by the kernel, with the ability to define a policy based on the caller information. For the details on expressing a policy, refer to Documentation/ABI/testing/ima-policy. For example, the new rules could be expressed like: measure func=KEXEC_CHECK appraise func=KEXEC_CHECK appraise_type=imasig # measure func=INITRAMFS_CHECK appraise func=INITRAMFS_CHECK appraise_type=imasig # measure func=FIRMWARE_CHECK appraise func=FIRMWARE_CHECK appraise_type=imasig # measure func=POLICY_CHECK appraise func=POLICY_CHECK appraise_type=imasig This policy flexibility is needed at least until all files come from software providers with file signatures. (RPM has been modified to include file signatures.) Even then, in terms of kexec, some distros generate the initramfs on the target host and, therefore, can not sign the initramfs. The local user could, however, sign the initramfs on their own system. Mimi ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [Linux-ima-devel] [PATCH v2 4/7] ima: measure and appraise kexec image and initramfs
On Tue, 2015-12-29 at 07:06 -0500, Mimi Zohar wrote: > On Tue, 2015-12-29 at 16:21 +0800, Dave Young wrote: > This policy flexibility is needed at least until all files come from > software providers with file signatures. (RPM has been modified to > include file signatures.) Even then, in terms of kexec, some distros > generate the initramfs on the target host and, therefore, can not sign > the initramfs. The local user could, however, sign the initramfs on > their own system. Sorry, instead of "local user" the "local system/host owner" would be more appropriate. Mimi ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
