Hi,
the UML page at http://user-mode-linux.sourceforge.net/old/skas.html
mentions that "The UML kernel is present in the address space of each of
its processes, and, by default, is writeable".
I tried to put this to a test, and actually failed to modify the
UML kernel/memory image from within it. I had a simple kernel module
with 'int val = 2;' and upon loading this, done printk("Val is at %p\n",
&val); to get to know the address. A userspace program inside the UML
then tried to dereference that address and read the value, but that
ended in a segfault. /proc/xxx/maps also does not show the UML kernel
being mapped in any process inside the UML. Note that I was running in
SKAS0 mode, both host and guest are all 64-bit. Is the NX bit of the
64-bit platform securing things off, or has SKAS3 become sort of
obsolete?
Jan
On Wed, Aug 27, 2008 at 12:57:53PM -0400, Jan Engelhardt wrote:
> the UML page at http://user-mode-linux.sourceforge.net/old/skas.html
> mentions that "The UML kernel is present in the address space of each of
> its processes, and, by default, is writeable".
That stuff, as you can see by the "old" in the URL, is old.
Since skas0 became the default, that statement is no longer true.
>
> I tried to put this to a test, and actually failed to modify the
> UML kernel/memory image from within it. I had a simple kernel module
> with 'int val = 2;' and upon loading this, done printk("Val is at %p\n",
> &val); to get to know the address. A userspace program inside the UML
> then tried to dereference that address and read the value, but that
> ended in a segfault. /proc/xxx/maps also does not show the UML kernel
> being mapped in any process inside the UML. Note that I was running in
> SKAS0 mode, both host and guest are all 64-bit. Is the NX bit of the
> 64-bit platform securing things off, or has SKAS3 become sort of
> obsolete?
SKAS3 is still a significant performance boost.
Jeff
--
Work email - jdike at linux dot intel dot com
On Wednesday 2008-08-27 15:06, Jeff Dike wrote:
>On Wed, Aug 27, 2008 at 12:57:53PM -0400, Jan Engelhardt wrote:
>>
>> I tried to put this to a test, and actually failed to modify the
>> UML kernel/memory image from within it. I had a simple kernel module
>> with 'int val = 2;' and upon loading this, done printk("Val is at %p\n",
>> &val); to get to know the address. A userspace program inside the UML
>> then tried to dereference that address and read the value, but that
>> ended in a segfault. /proc/xxx/maps also does not show the UML kernel
>> being mapped in any process inside the UML. Note that I was running in
>> SKAS0 mode, both host and guest are all 64-bit. Is the NX bit of the
>> 64-bit platform securing things off, or has SKAS3 become sort of
>> obsolete?
>
>SKAS3 is still a significant performance boost.
In tests of mine, oggenc in SKAS0 mode ran at 95% of native speed, which
is pretty good.
On Wed, Aug 27, 2008 at 04:00:24PM -0400, Jan Engelhardt wrote:
> In tests of mine, oggenc in SKAS0 mode ran at 95% of native speed, which
> is pretty good.
Different workloads give different results. Yours sounds
CPU-intensive. Kernel builds here run at 50-60% of native with skas0,
low 80's with skas3, and ~86% with skas4.
Jeff
--
Work email - jdike at linux dot intel dot com
On 27 Aug 2008, Jeff Dike stated:
> SKAS3 is still a significant performance boost.
Nobody's forward-ported it to recent kernels that I can see, though :/
--
`Not even vi uses vi key bindings for its command line.' --- PdS