Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1487735 > unrolled thread

Re: [RFC 0/3] Put vdso in ramfs-like filesystem (vdsofs)

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [RFC 0/3] Put vdso in ramfs-like filesystem (vdsofs) "H. Peter Anvin" <hpa@zytor.com> - 2016-09-21 02:30 +0200
    Re: [RFC 0/3] Put vdso in ramfs-like filesystem (vdsofs) "H. Peter Anvin" <hpa@zytor.com> - 2016-09-21 02:40 +0200
      Re: [RFC 0/3] Put vdso in ramfs-like filesystem (vdsofs) Andy Lutomirski <luto@amacapital.net> - 2016-09-21 03:00 +0200
        Re: [RFC 0/3] Put vdso in ramfs-like filesystem (vdsofs) "H. Peter Anvin" <hpa@zytor.com> - 2016-09-21 03:10 +0200
          Re: [RFC 0/3] Put vdso in ramfs-like filesystem (vdsofs) "H. Peter Anvin" <hpa@zytor.com> - 2016-09-21 03:20 +0200
            Re: [RFC 0/3] Put vdso in ramfs-like filesystem (vdsofs) Andy Lutomirski <luto@amacapital.net> - 2016-09-21 08:50 +0200

#1487735 — Re: [RFC 0/3] Put vdso in ramfs-like filesystem (vdsofs)

The more I'm thinking about this, why don't we simply have these (the
various possible vdsos as well as vvar) as actual files in sysfs instead
of introducing a new filesystem?  I don't believe sysfs actually has to
be mounted in order for sysfs files to have an inode.

It could also be in procfs, I guess, but sysfs probably makes more sense.

I'm thinking something like:

/sys/kernel/vdso/{i386,x86_64,x32,vvar}

Not only would this let the container people and so on do weird things
much easier, but it ought to eliminate a whole slew of special cases.


	-hpa

[toc] | [next] | [standalone]

#1487738

On 09/20/16 17:22, H. Peter Anvin wrote:
> The more I'm thinking about this, why don't we simply have these (the
> various possible vdsos as well as vvar) as actual files in sysfs instead
> of introducing a new filesystem?  I don't believe sysfs actually has to
> be mounted in order for sysfs files to have an inode.
> 
> It could also be in procfs, I guess, but sysfs probably makes more sense.
> 
> I'm thinking something like:
> 
> /sys/kernel/vdso/{i386,x86_64,x32,vvar}
> 
> Not only would this let the container people and so on do weird things
> much easier, but it ought to eliminate a whole slew of special cases.
> 

Even crazier idea: instead of a separate vvar file, have the vvar page
just be a part of these files (as a shared page)... I'm wondering if we
can even use load_elf_interp() since after all it is an ELF shared
library image...

	-hpa

[toc] | [prev] | [next] | [standalone]

#1487743

On Tue, Sep 20, 2016 at 5:32 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 09/20/16 17:22, H. Peter Anvin wrote:
>> The more I'm thinking about this, why don't we simply have these (the
>> various possible vdsos as well as vvar) as actual files in sysfs instead
>> of introducing a new filesystem?  I don't believe sysfs actually has to
>> be mounted in order for sysfs files to have an inode.
>>
>> It could also be in procfs, I guess, but sysfs probably makes more sense.
>>
>> I'm thinking something like:
>>
>> /sys/kernel/vdso/{i386,x86_64,x32,vvar}
>>
>> Not only would this let the container people and so on do weird things
>> much easier, but it ought to eliminate a whole slew of special cases.
>>
>
> Even crazier idea: instead of a separate vvar file, have the vvar page
> just be a part of these files (as a shared page)... I'm wondering if we
> can even use load_elf_interp() since after all it is an ELF shared
> library image...

I think that may be too crazy:

 - If vvar is in the same inode, then that inode won't be a valid ELF
image, because the ELF header won't be in the right place.

 - vvar is highly magical.  IMO letting it get mapped with VM_MAYWRITE
is asking for trouble, as anything that writes it will COW it, leading
to strange malfunctions.

 - vvar can, and has, had IO pages in it.  This means that the actual
cache types can vary page-to-page in the vvar area, which is not
something that ordinary files do.

Also, if we let the users get an fd pointing to the vdso, then we're
more or less committing to never having contents in the vdso text that
vary per-process.  Are we okay with that.

Dmitry's patches have the vdso using the page cache, and I'm not sure
that even that is needed.  I think that a file with no backing
address_space that simply provides vm_fault instead may be sufficient,
especially for vvar.  I don't know if uprobes would be okay with that,
though.

My personal preference is to let them both be real struct file *
objects (possibly shared between all processes of the same vdso ABI)
but to prevent user code from ever creating an fd referring to one of
these files.

--Andy

[toc] | [prev] | [next] | [standalone]

#1487745

On 09/20/16 17:54, Andy Lutomirski wrote:
>  - If vvar is in the same inode, then that inode won't be a valid ELF
> image, because the ELF header won't be in the right place.

So the vvar ought to move into an actual ELF segment, which is probably
The Right Thing anyway.

>  - vvar is highly magical.  IMO letting it get mapped with VM_MAYWRITE
> is asking for trouble, as anything that writes it will COW it, leading
> to strange malfunctions.
> 
>  - vvar can, and has, had IO pages in it.  This means that the actual
> cache types can vary page-to-page in the vvar area, which is not
> something that ordinary files do.

Neither of these are any different than many devices, or various files
in procfs.

> My personal preference is to let them both be real struct file *
> objects (possibly shared between all processes of the same vdso ABI)
> but to prevent user code from ever creating an fd referring to one of
> these files.

Why?  It would help people doing weird things like process snapshotting
or bimodal execution enormously.  We want to share an inode, obviously;
the pointer is another issue.

> Also, if we let the users get an fd pointing to the vdso, then we're
> more or less committing to never having contents in the vdso text that
> vary per-process.  Are we okay with that.

This might be a reason to put these objects in procfs rather than sysfs,
but I have to admit that this seems *extremely* far fetched to me.
Obviously they vary per process in the sense that there are already
several to choose from.  In the case of process-unique vdsos there would
be a large number of them, of course.

	-hpa

[toc] | [prev] | [next] | [standalone]

#1487749

On 09/20/16 18:07, H. Peter Anvin wrote:
> 
>>  - vvar is highly magical.  IMO letting it get mapped with VM_MAYWRITE
>> is asking for trouble, as anything that writes it will COW it, leading
>> to strange malfunctions.
>>

The vvar page obviously needs to be mapped MAP_SHARED, and the
underlying file needs to reject writes.  A solution where this area
doesn't end up MAP_SHARED is obviously defective.

As far as keeping the user from doing really stupid things... they can
map a RAM page over the vvar area and there is nothing the kernel really
can do to keep them from doing something like that without doing things
that are probably way worse than the disease.  At least it will be
obvious looking at the mapping file what is going on.

	-hpa

[toc] | [prev] | [next] | [standalone]

#1487839

> On 09/20/16 18:07, H. Peter Anvin wrote:
> >
> >>  - vvar is highly magical.  IMO letting it get mapped with VM_MAYWRITE
> >> is asking for trouble, as anything that writes it will COW it, leading
> >> to strange malfunctions.
> >>
>
> The vvar page obviously needs to be mapped MAP_SHARED, and the
> underlying file needs to reject writes.  A solution where this area
> doesn't end up MAP_SHARED is obviously defective.

Hmm, maybe.  But it does certainly work now, and I'm not sure what we
gain by making it more file-like than needed.  Using a non-null
vm_file removes tons of special cases, but giving it a real
address_space doesn't seem very useful to me.

>
> As far as keeping the user from doing really stupid things... they can
> map a RAM page over the vvar area and there is nothing the kernel really
> can do to keep them from doing something like that without doing things
> that are probably way worse than the disease.  At least it will be
> obvious looking at the mapping file what is going on.

I don't want an overly clever debugger to poke the page.  MAP_SHARED
might be sufficient.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web