linux-kernel - Re: [PATCH] staging: tidspbridge

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] [day] [month] [year] [list]

Message-ID: <AANLkTi=g+Z1wGHYGUZFRZFPTyYVadQiHm7Ex3ET0PcVz@mail.gmail.com>
Date:	Wed, 5 Jan 2011 13:45:12 -0600
From:	"Guzman Lugo, Fernando" <fernando.lugo@...com>
To:	"Ramirez Luna, Omar" <omar.ramirez@...com>
Cc:	gregkh@...e.de, rene.sapiens@...com, devel@...verdev.osuosl.org,
	linux-kernel@...r.kernel.org, linux-omap@...r.kernel.org,
	Felipe Contreras <felipe.contreras@...ia.com>
Subject: Re: [PATCH] staging: tidspbridge - configure full L1 MMU range

On Wed, Jan 5, 2011 at 12:46 PM, Ramirez Luna, Omar <omar.ramirez@...com> wrote:
> Hi,
>
> On Wed, Jan 5, 2011 at 12:20 AM, Fernando Guzman Lugo
> <fernando.lugo@...com> wrote:
>> Otherwise a virtual address beyond of the L1 size is used,
>> the MMU hardware will look into a memory that does not belong to
>> L1 translation tables. IOW; the MMU would allow to access any
>> memory, configured or not.
>>
>
> How about:
>
> IVA MMU can manage up to 4GB of address space through its page tables,
> given that it's L1 is divided into 1MB sections it requires at least
> 16KB for its table which represents 4096 entries of 32 bits each.
>
> Previously, only 1GB was being handled by setting the page table size
> to 4KB, any virtual address beyond of the L1 size used, would fall
> into memory that does not belong to L1 translation tables, leading to
> unpredictable results.
>
> So, set the L1 table size to cover the entire MMU range (4GB) whether
> is meant to be used or not.

looks good to me.

>
>> Reported-by: Felipe Contreras <felipe.contreras@...ia.com>
>> Signed-off-by: Fernando Guzman Lugo <fernando.lugo@...com>
>> Signed-off-by: Felipe Contreras <felipe.contreras@...ia.com>
>> ---
>>  drivers/staging/tidspbridge/core/tiomap3430.c |    6 ++----
>>  1 files changed, 2 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/staging/tidspbridge/core/tiomap3430.c b/drivers/staging/tidspbridge/core/tiomap3430.c
>> index 1be081f..ec96d1e 100644
>> --- a/drivers/staging/tidspbridge/core/tiomap3430.c
>> +++ b/drivers/staging/tidspbridge/core/tiomap3430.c
>> @@ -70,6 +70,7 @@
>>  #define MMU_LARGE_PAGE_MASK      0xFFFF0000
>>  #define MMU_SMALL_PAGE_MASK      0xFFFFF000
>>  #define OMAP3_IVA2_BOOTADDR_MASK 0xFFFFFC00
>> +#define MMU_L1_SIZE              0x4000
>>  #define PAGES_II_LVL_TABLE   512
>>  #define PHYS_TO_PAGE(phys)      pfn_to_page((phys) >> PAGE_SHIFT)
>>
>> @@ -786,10 +787,7 @@ static int bridge_dev_create(struct bridge_dev_context
>>
>>        pt_attrs = kzalloc(sizeof(struct pg_table_attrs), GFP_KERNEL);
>>        if (pt_attrs != NULL) {
>> -               /* Assuming that we use only DSP's memory map
>> -                * until 0x4000:0000 , we would need only 1024
>> -                * L1 enties i.e L1 size = 4K */
>> -               pt_attrs->l1_size = 0x1000;
>> +               pt_attrs->l1_size = MMU_L1_SIZE;
>
> How about using SZ_16K instead, struct member name already specifies
> it is L1 size, is the new define needed?

Ok, maybe a comment to state why 16K is used should be good.

I will make the changes.

Regards,
Fernando.

>
> Regards,
>
> Omar
>
--
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/