tech-kern archive

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

Re: Removing dbregs



On 13.07.2018 23:32, Jason Thorpe wrote:
> 
> 
>> On Jul 13, 2018, at 2:22 PM, Kamil Rytarowski <n54%gmx.com@localhost> wrote:
>>
>> On 13.07.2018 23:10, Jaromír Doleček wrote:
>>> 2018-07-13 22:54 GMT+02:00 Kamil Rytarowski <n54%gmx.com@localhost>:
>>>> I disagree with disabling it. The code is not broken, it's covered by
>>>> tests, it's in use.
>>>
>>> This looks like perfect candidate for optional (default off) feature.
>>> It is useless and dangerous for general purpose use by virtue of being
>>> root only, but useful for specialized use.
>>>
>>> Honestly, I don't see any reason to have this on by default.
> 
> A sysctl is kind of lame, because it can also result in a branch prediction miss.
> 
> Protect the sysctl in an #ifdef to enable being able to enable the feature?
> 

This sysctl does not disable the feature in the kernel, it is designed
to control the security extension value whether a user is allowed to set
these registers. A user is still allowed to read them always.

security.models.extensions.user_set_dbregs = 0  # <- here DB registers

It's integrated into the security framework in the kernel that checks
whether write operation is allowed.

#ifdefing it out in a non-benchmarking application (I was checking ones
that do something with syscalls) is more negligible than 0,3% of
overhead in the kernel in a loop.

However if there is a general consensus that this is a must-have and
urgent, I can dedicate time for this.. CC: Christos / Alistair.

Attachment: signature.asc
Description: OpenPGP digital signature



Home | Main Index | Thread Index | Old Index