linux-kernel - Re: [PATCH v2 1/1] x86: Add Isolated Memory Regions for Quark X1000

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 24 Jan 2015 19:52:07 +0000
From:	Bryan O'Donoghue <pure.logic@...us-software.ie>
To:	"Ong, Boon Leong" <boon.leong.ong@...el.com>
CC:	"tglx@...utronix.de" <tglx@...utronix.de>,
	"mingo@...hat.com" <mingo@...hat.com>,
	"hpa@...or.com" <hpa@...or.com>, "x86@...nel.org" <x86@...nel.org>,
	"dvhart@...radead.org" <dvhart@...radead.org>,
	"andy.shevchenko@...il.com" <andy.shevchenko@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 1/1] x86: Add Isolated Memory Regions for Quark X1000

On 24/01/15 01:48, Ong, Boon Leong wrote:

Skipping stuff I agree with.

>  From V1 comment:
> Suggest to add a statement on 3 different types of IMR: General IMR, Host Memory
> I/O Boundary IMR & System Management Mode IMR. Then, call out that this patch
> is meant to support general IMR type only.

Hmm - There's no mention of grouping like that in the documentation, nor 
in released silicon - to my knowledge.

Also why do you want a statement added saying that it supports CPU only 
mode ?

This patch will support adding IMRs for SMM mode - if calling code wants 
do do that - it's just imr_add_range(base, size, SMM, SMM);

Same thing with virtual-channels, RMU, etc.


>> +	ret = imr_check_range(base, size);
>> +	if (ret)
>> +		return ret;
>> +
>> +	if (size < IMR_ALIGN)
>> +		return -EINVAL;
> I believe this is redundant because imr_check_range() has test for (size & IMR_MASK)
> which means if the size is indeed smaller than 0x400, the test will caught it anyway.

Nope.

(0 & 0x3FF) == 0

We need to bounds check for a zero size.

I'll change it to

if (size == 0)
	return -EINVAL;

to avoid confusion.

>> +
>> +	/* Tweak the size value */
>> +	size = imr_fixup_size(size);
>> +	pr_debug("IMR %d phys 0x%08lx-0x%08lx rmask 0x%08x wmask
>> 0x%08x\n",
>> +		reg, base, end, rmask, wmask);
> Do we want to account for the 'size fixup' above on 'end'
>> +
>> +	/* Allocate IMR */
>> +	imr.addr_lo = phys_to_imr(base);
>> +	imr.addr_hi = phys_to_imr(end);
>
> The fix-up size above is never factored here ...
> 'end-size' should be the correct one

hmmm.

The correct fix is

size = imr_fixup_size(size);
end = base + size;

>> +	} else {
>> +		/* Search for match based on address range */
>> +		for (i = 0; i < imr_dev.max_imr; i++) {
>> +			ret = imr_read(reg, &imr);
> A serious bug here.... 'reg' should be 'i' . We enter this branch if reg=-1
> Is there a miss in your test case?

Hmm you're right.

Turns out there's only the one test case for imr_del_range();

Good catch.

--
BOD

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/