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: <3dbd167f-c381-8451-5861-3788634885b7@redhat.com>
Date:   Mon, 25 Sep 2017 11:26:27 -0700
From:   Laura Abbott <labbott@...hat.com>
To:     Benjamin Gaignard <benjamin.gaignard@...aro.org>,
        sumit.semwal@...aro.org, gregkh@...uxfoundation.org,
        arve@...roid.com, riandrews@...roid.com, broonie@...nel.org,
        dan.carpenter@...cle.com
Cc:     devel@...verdev.osuosl.org, linux-kernel@...r.kernel.org,
        dri-devel@...ts.freedesktop.org
Subject: Re: [PATCH v3 2/2] staging: ion: create one device entry per heap

On 09/20/2017 01:45 AM, Benjamin Gaignard wrote:
> Instead a getting one common device "/dev/ion" for
> all the heaps this patch allow to create one device
> entry ("/dev/ionX") per heap.
> Getting an entry per heap could allow to set security rules
> per heap and global ones for all heaps.
> 
> Allocation requests will be only allowed if the mask_id
> match with device minor.
> Query request could be done on any of the devices.
> Deivce node major will also change and that may impact init scripts.
> 

We should start Cc linux-api for future changes since we're going
to have more than just /dev/ion.

Thinking about this some more, I think we need to allow backwards
compatibility. It's just not feasible to keep throwing workarounds
into userspace if we can avoid it. I'd propose keeping the old /dev/ion
misc interface available under a Kconfig and then creating the new
split heaps in parallel.

On a somewhat related note, there was some interest in possibly
having a sysfs interface for Ion long term. I don't think this
needs to happen right now but I'd like whatever we do to not
make adding that harder.

Thanks,
Laura

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ