* Reusable Memory Manager
@ 2015-04-23 2:39 Kenneth Adam Miller
2015-04-23 2:42 ` nick
0 siblings, 1 reply; 3+ messages in thread
From: Kenneth Adam Miller @ 2015-04-23 2:39 UTC (permalink / raw)
To: kernelnewbies
So, I have a particular use case that has a lot to do with security.
Basically, we have a intended secure kernel version with grsecurity and
other patches on it, and we have a specific application that has to do data
filtering as an inline reference monitor.
The problem is, there is throughput and design considerations that are
limiting efficiency in the sense that it is highly difficult to make the
system concurrent and also highly difficult to scale-all while also being
secure.
Basically, the memory regions have to be encoded at compile time because of
the way kernel segregation works. This makes the security proof of the
system far more simple and manageable; it's easy to say that no userland
monitor which is being given access to a specific memory region can access
outside of the region to which it is allocated, because it's statically
set. The tradeoff here is pretty severe, because the static settings that
have to be adopted pretty much mean that each particular monitor is given a
specific memory region; if there's a lot of traffic to a specific monitor
type, then that one type will be overwhelmed, but not even at the rate that
the machine itself could support. This is because all the other cores are
potentially sitting unused while the one in this worst case scenario is
running out of memory and not able to dispatch work to more cores.
So my ultimate question is: is there some reusable, dynamic memory
allocation manager that can be used? I'm thinking that there has to, at the
least, be the constructs by which user land processes are managed and
divvied memory by the kernel itself. Does anybody know where that source
would be? Where I can go in order to learn more about that?
What we want is a secure way to dynamically allocate memory from these
static memory page boundaries such that
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150422/c69de846/attachment.html
^ permalink raw reply [flat|nested] 3+ messages in thread
* Reusable Memory Manager
2015-04-23 2:39 Reusable Memory Manager Kenneth Adam Miller
@ 2015-04-23 2:42 ` nick
[not found] ` <CAK7rcp9XqBjZ4Sp8-C=jQE0OSnxqNoLVFntCowVQSR=6iBMvsQ@mail.gmail.com>
0 siblings, 1 reply; 3+ messages in thread
From: nick @ 2015-04-23 2:42 UTC (permalink / raw)
To: kernelnewbies
On 2015-04-22 10:39 PM, Kenneth Adam Miller wrote:
> So, I have a particular use case that has a lot to do with security.
>
> Basically, we have a intended secure kernel version with grsecurity and
> other patches on it, and we have a specific application that has to do data
> filtering as an inline reference monitor.
>
> The problem is, there is throughput and design considerations that are
> limiting efficiency in the sense that it is highly difficult to make the
> system concurrent and also highly difficult to scale-all while also being
> secure.
>
> Basically, the memory regions have to be encoded at compile time because of
> the way kernel segregation works. This makes the security proof of the
> system far more simple and manageable; it's easy to say that no userland
> monitor which is being given access to a specific memory region can access
> outside of the region to which it is allocated, because it's statically
> set. The tradeoff here is pretty severe, because the static settings that
> have to be adopted pretty much mean that each particular monitor is given a
> specific memory region; if there's a lot of traffic to a specific monitor
> type, then that one type will be overwhelmed, but not even at the rate that
> the machine itself could support. This is because all the other cores are
> potentially sitting unused while the one in this worst case scenario is
> running out of memory and not able to dispatch work to more cores.
>
> So my ultimate question is: is there some reusable, dynamic memory
> allocation manager that can be used? I'm thinking that there has to, at the
> least, be the constructs by which user land processes are managed and
> divvied memory by the kernel itself. Does anybody know where that source
> would be? Where I can go in order to learn more about that?
>
> What we want is a secure way to dynamically allocate memory from these
> static memory page boundaries such that
>
>
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
You didn't finish your email such that ... . I would be glad to try and
help if you finish off what your requirements are.
Nick
^ permalink raw reply [flat|nested] 3+ messages in thread
* Reusable Memory Manager
[not found] ` <CAK7rcp9XqBjZ4Sp8-C=jQE0OSnxqNoLVFntCowVQSR=6iBMvsQ@mail.gmail.com>
@ 2015-04-23 3:01 ` nick
0 siblings, 0 replies; 3+ messages in thread
From: nick @ 2015-04-23 3:01 UTC (permalink / raw)
To: kernelnewbies
On 2015-04-22 10:47 PM, Kenneth Adam Miller wrote:
> On Wed, Apr 22, 2015 at 10:42 PM, nick <xerofoify@gmail.com> wrote:
>
>>
>>
>> On 2015-04-22 10:39 PM, Kenneth Adam Miller wrote:
>>> So, I have a particular use case that has a lot to do with security.
>>>
>>> Basically, we have a intended secure kernel version with grsecurity and
>>> other patches on it, and we have a specific application that has to do
>> data
>>> filtering as an inline reference monitor.
>>>
>>> The problem is, there is throughput and design considerations that are
>>> limiting efficiency in the sense that it is highly difficult to make the
>>> system concurrent and also highly difficult to scale-all while also being
>>> secure.
>>>
>>> Basically, the memory regions have to be encoded at compile time because
>> of
>>> the way kernel segregation works. This makes the security proof of the
>>> system far more simple and manageable; it's easy to say that no userland
>>> monitor which is being given access to a specific memory region can
>> access
>>> outside of the region to which it is allocated, because it's statically
>>> set. The tradeoff here is pretty severe, because the static settings that
>>> have to be adopted pretty much mean that each particular monitor is
>> given a
>>> specific memory region; if there's a lot of traffic to a specific monitor
>>> type, then that one type will be overwhelmed, but not even at the rate
>> that
>>> the machine itself could support. This is because all the other cores are
>>> potentially sitting unused while the one in this worst case scenario is
>>> running out of memory and not able to dispatch work to more cores.
>>>
>>> So my ultimate question is: is there some reusable, dynamic memory
>>> allocation manager that can be used? I'm thinking that there has to, at
>> the
>>> least, be the constructs by which user land processes are managed and
>>> divvied memory by the kernel itself. Does anybody know where that source
>>> would be? Where I can go in order to learn more about that?
>>>
>>> What we want is a secure way to dynamically allocate memory from these
>>> static memory page boundaries such that
>>>
>>>
>>>
>>> _______________________________________________
>>> Kernelnewbies mailing list
>>> Kernelnewbies at kernelnewbies.org
>>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>>
>> You didn't finish your email such that ... . I would be glad to try and
>> help if you finish off what your requirements are.
>> Nick
>>
>
>
> Ooops, sorry, I didn't know that last fragment was there. I think the
> previous part explains what I am looking for.
>
That's OK. You may want to look into virtual memory management of the kernel. However,
I doubt that's what you want the issue is some that reallocates and takes advantage
of CPU and already allowed kernel date structures. If that is the case look into writing
a slab allocator for your security features you have added to the kernel. Further more
writing a slab allocator is non trivial and you will need to look into the way memory is
being handled in terms of hardware caches to find the best options with the slab functions
in the kernel to get the best performable slab for your needs.This is link to a chapter
in a book explaining this,https://www.kernel.org/doc/gorman/html/understand/understand011.htm.
The only issue is the book is outdated in terms of kernel releases but the concepts are
similar if not identical to the current releases.
Hope this Helps,
Nick
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2015-04-23 3:01 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-04-23 2:39 Reusable Memory Manager Kenneth Adam Miller
2015-04-23 2:42 ` nick
[not found] ` <CAK7rcp9XqBjZ4Sp8-C=jQE0OSnxqNoLVFntCowVQSR=6iBMvsQ@mail.gmail.com>
2015-04-23 3:01 ` nick
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).