linux-kernel - Re: [PATCH] hpet, allow user controlled mmap for user processes

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]

Message-ID: <5148747C.9020803@redhat.com>
Date:	Tue, 19 Mar 2013 10:21:48 -0400
From:	Prarit Bhargava <prarit@...hat.com>
To:	Clemens Ladisch <clemens@...isch.de>
CC:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] hpet, allow user controlled mmap for user processes



On 03/19/2013 03:43 AM, Clemens Ladisch wrote:
> Prarit Bhargava wrote:
>> The CONFIG_HPET_MMAP Kconfig option exposes the memory map of the HPET
>> registers to userspace.  The Kconfig help points out that in some cases this
>> can be a security risk as some systems may erroneously configure the map such
>> that additional data is exposed to userspace.
>>
>> This is a problem for distributions -- some users want the MMAP functionality
>> but it comes with a significant security risk.  In an effort to mitigate this
>> risk, and due to the low number of users of the MMAP functionality, I've
>> introduced a kernel parameter, hpet_mmap_enable, that is required in order
>> to actually have the HPET MMAP exposed.
>>
>> [v2]: Clemens suggested modifying the Kconfig help text and making the
>> default setting configurable.
>>
>> Signed-off-by: Prarit Bhargava <prarit@...hat.com>
>> Cc: Clemens Ladisch <clemens@...isch.de>
> 
>> +++ b/Documentation/kernel-parameters.txt
>> +	hpet_mmap_enable [X86, HPET_MMAP] option to expose HPET MMAP to
>> +			 userspace.  By default this is disabled.
> 
> This now takes a value.
> 
>> +	int "Enable HPET MMAP access by default"
>> +	range 0 1
> 
> Shouldn't this be bool?

I'll fix those in v3.

> 
>> +	default 0
> 
> This breaks backwards compatibility.

Does backwards compatibility matter for something like?  I have no problem
setting it to 1 but I'm more curious from a general kernel point of view.

I'll change this in v3 as well.

P.


P.

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