Re: [PATCH 02/17] prmem: write rare for static allocation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 26/10/2018 10:41, Peter Zijlstra wrote:
On Wed, Oct 24, 2018 at 12:34:49AM +0300, Igor Stoppa wrote:
+static __always_inline

That's far too large for inline.

The reason for it is that it's supposed to minimize the presence of gadgets that might be used in JOP attacks. I am ready to stand corrected, if I'm wrong, but this is the reason why I did it.

Regarding the function being too large, yes, I would not normally choose it for inlining.

Actually, I would not normally use "__always_inline" and instead I would limit myself to plain "inline", at most.


+bool wr_memset(const void *dst, const int c, size_t n_bytes)
+{
+	size_t size;
+	unsigned long flags;
+	uintptr_t d = (uintptr_t)dst;
+
+	if (WARN(!__is_wr_after_init(dst, n_bytes), WR_ERR_RANGE_MSG))
+		return false;
+	while (n_bytes) {
+		struct page *page;
+		uintptr_t base;
+		uintptr_t offset;
+		uintptr_t offset_complement;
+
+		local_irq_save(flags);
+		page = virt_to_page(d);
+		offset = d & ~PAGE_MASK;
+		offset_complement = PAGE_SIZE - offset;
+		size = min(n_bytes, offset_complement);
+		base = (uintptr_t)vmap(&page, 1, VM_MAP, PAGE_KERNEL);
+		if (WARN(!base, WR_ERR_PAGE_MSG)) {
+			local_irq_restore(flags);
+			return false;
+		}
+		memset((void *)(base + offset), c, size);
+		vunmap((void *)base);

BUG

yes, somehow I managed to drop this debug configuration from the debug builds I made.

[...]

Also, I see an amount of duplication here that shows you're not nearly
lazy enough.

I did notice a certain amount of duplication, but I didn't know how to exploit it.

--
igor



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux Kernel]     [Linux Kernel Hardening]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux SCSI]

  Powered by Linux