[PATCH prototype] [0/8] Predictive bitmaps for ELF executables - Kernel

This is a discussion on [PATCH prototype] [0/8] Predictive bitmaps for ELF executables - Kernel ; On Wed, Mar 19, 2008 at 03:45:16PM -0700, Ulrich Drepper wrote: > On Wed, Mar 19, 2008 at 2:04 AM, Andrew Morton > wrote: > > The requirement to write to an executable sounds like a bit of a > ...

+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast
Results 21 to 40 of 41

Thread: [PATCH prototype] [0/8] Predictive bitmaps for ELF executables

  1. Re: [PATCH prototype] [0/8] Predictive bitmaps for ELF executables

    On Wed, Mar 19, 2008 at 03:45:16PM -0700, Ulrich Drepper wrote:
    > On Wed, Mar 19, 2008 at 2:04 AM, Andrew Morton
    > wrote:
    > > The requirement to write to an executable sounds like a bit of a
    > > showstopper.

    >
    > Agreed. In addition, it makes all kinds of tools misbehave. I can
    > see extensions to the ELF format and those would require relinking
    > binaries, but without this you create chaos. ELF is so nice because


    What chaos exactly? For me it looks rather that a separatate database
    would be a recipe for chaos. e.g. for example how would you make sure
    the database keeps track of changing executables?

    The only minor issue is rpm -Va and similar, but that can be handled
    in the same way as prelinking is handled there by using filter scripts
    that reset the bitmap before taking a checksum.

    Also the current way does not require relinking by using the shdr hack.
    I have a simple program that adds a bitmap shdr to any executable.
    But if the binutils leanred about this and added a bitmap phdr (it
    tends to be only a few hundred bytes even on very large executables)
    one seek could be avoided.


    > it describes the entire file and we can handle everything according to
    > rules. If you just somehow magically patch some new data structure in
    > this will break things.


    Can you elaborate what you think will be broken?

    >
    > Furthermore, by adding all this data to the end of the file you'll


    We are talking about 32bytes for each MB worth of executable.
    You can hardly call that "all that data". Besides the prefetcher supports
    in theory larger page sizes, so if you wanted you could even reduce
    that even more by e.g. using 64k prefetch blocks. But the overhead
    is so tiny that it doesn't make much difference.

    > normally create unnecessary costs. The parts of the binaries which
    > are used at runtime start at the front. At the end there might be a
    > lot of data which isn't needed at runtime and is therefore normally
    > not read.


    Yes as I said using the SHDR currently requires an additional seek
    (although in practice i expect it to be served out of the track
    buffer of the hard disk if the executable is not too large and is
    continuous on disk). If binutils were taught of generating a phdr
    that minor problem would go away.

    >
    >
    > > if it proves useful, build it all into libc..

    >
    > I could see that. But to handle it efficiently kernel support is
    > needed. Especially since I don't think the currently proposed


    I agree.

    > "learning mode" is adequate. Over many uses of a program all kinds of


    It is not too bad, but could be certainly better. I outlined
    some possible ways to improve the algorithms in my original way.
    It would be a nice research project for someone to investigate
    the various ways (anyone interested?)

    > pages will be needed. Far more than in most cases. The prefetching
    > should really only cover the commonly used code paths in the program.


    Sorry that doesnt make sense. Anything that is read at startup
    has to be prefetched, even if that code is only executed once.
    Otherwise the whole scheme is rather useless.
    Because even a single access requires the IO to read it from
    disk.

    > If you pull in everything, this will have advantages if you have that
    > much page cache to spare. In that case just prefetching the entire


    Yes that is what the "mmap_flush" hack (last patch does) I actually
    have some numbers on a older kernel and in some cases it really
    does quite well. But it also has a few problems (e.g. interaction
    with data mmaps and memory waste) that are unpleasant.

    -Andi
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. Re: [PATCH prototype] [0/8] Predictive bitmaps for ELF executables

    On Thu, Mar 20, 2008 at 2:00 AM, Andi Kleen wrote:
    > What chaos exactly? For me it looks rather that a separatate database
    > would be a recipe for chaos. e.g. for example how would you make sure
    > the database keeps track of changing executables?


    I didn't say that a separate file with the data is better. In fact, I
    agree, it's not much better. What I referred to as the problem is
    that this is an extension which is not part of the ELF spec and
    doesn't fit in. The ELF spec has rules how programs have to deal with
    unknown parts of a binary. Only this way programs like strip can work
    in the presence of extensions. There are ways to embed such a bitmap
    but not ad-hoc as you proposed.


    > But if the binutils leanred about this and added a bitmap phdr (it
    > tends to be only a few hundred bytes even on very large executables)
    > one seek could be avoided.


    And that is only one advantage. Let's not go done the path of invalid
    ELF files.


    > > Furthermore, by adding all this data to the end of the file you'll

    >
    > We are talking about 32bytes for each MB worth of executable.
    > You can hardly call that "all that data".


    This wasn't a comment about the size of the data but the type of data.
    The end of a binary contains data which is not used at runtime. Now
    you're mixing in data which is used.


    > > pages will be needed. Far more than in most cases. The prefetching
    > > should really only cover the commonly used code paths in the program.

    >
    > Sorry that doesnt make sense. Anything that is read at startup
    > has to be prefetched, even if that code is only executed once.
    > Otherwise the whole scheme is rather useless.
    > Because even a single access requires the IO to read it from
    > disk.


    Again, you misunderstand. I'm not proposing to exclude pages which
    are only used at startup time. I mean the data collection should stop
    some time after a process was started to account for possibly quite
    different code paths which are taken by different runs of the program.
    I.e., don't record page faults for the entire runtime of the program
    which, hopefully in most cases, will result in all the pages of a
    program to be marked (unless you have a lot of dead code in the binary
    and it's all located together).
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  3. Re: [PATCH prototype] [0/8] Predictive bitmaps for ELF executables

    On Fri, Mar 21, 2008 at 10:15:15AM -0700, Ulrich Drepper wrote:
    > On Thu, Mar 20, 2008 at 2:00 AM, Andi Kleen wrote:
    > > What chaos exactly? For me it looks rather that a separatate database
    > > would be a recipe for chaos. e.g. for example how would you make sure
    > > the database keeps track of changing executables?

    >
    > I didn't say that a separate file with the data is better. In fact, I
    > agree, it's not much better. What I referred to as the problem is
    > that this is an extension which is not part of the ELF spec and


    Linux executables already contain plenty of extensions outside
    the ELF spec like GNU_EH_FRAME or debuglink etc. It is not surprising
    because the ELF spec is kind of not maintained anymore afaik.

    > doesn't fit in. The ELF spec has rules how programs have to deal with
    > unknown parts of a binary. Only this way programs like strip can work


    Can you expand how the bitmap headers or pbitmap.c violate these rules?

    > in the presence of extensions. There are ways to embed such a bitmap
    > but not ad-hoc as you proposed.


    Concrete suggestions please.

    >
    >
    > > But if the binutils leanred about this and added a bitmap phdr (it
    > > tends to be only a few hundred bytes even on very large executables)
    > > one seek could be avoided.

    >
    > And that is only one advantage. Let's not go done the path of invalid
    > ELF files.


    What is invalid?

    >
    >
    > > > Furthermore, by adding all this data to the end of the file you'll

    > >
    > > We are talking about 32bytes for each MB worth of executable.
    > > You can hardly call that "all that data".

    >
    > This wasn't a comment about the size of the data but the type of data.
    > The end of a binary contains data which is not used at runtime. Now
    > you're mixing in data which is used.


    Well there was no other choice I know of short of relinking. Or do you
    have a way to add a PHDR without relinking? I am aware the SHDR is a hack,
    I called it that myself. I just don't know of a better way.

    If the pbitmaps were universally adopted the use of the SHDRs would
    be phased out quickly I expect because the bitmaps would be standard
    parts of all PHDRs, but short term not requiring relinking
    is a huge advantage.

    > Again, you misunderstand. I'm not proposing to exclude pages which
    > are only used at startup time. I mean the data collection should stop
    > some time after a process was started to account for possibly quite
    > different code paths which are taken by different runs of the program.
    > I.e., don't record page faults for the entire runtime of the program
    > which, hopefully in most cases, will result in all the pages of a
    > program to be marked (unless you have a lot of dead code in the binary
    > and it's all located together).


    When would that time be? I cannot think of a single heuristic that would
    work for both "/bin/true" and a OpenOffice start.

    -Andi
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  4. Re: [PATCH prototype] [0/8] Predictive bitmaps for ELF executables

    On Fri, Mar 21, 2008 at 10:26 AM, Andi Kleen wrote:
    > Concrete suggestions please.


    I already spelled it out. Add a new program header entry, point it to
    a bit array large enough to cover all loadable segments.

    It is not worth creating problems with this invalid extension just for
    old binaries. Just let those go. New binaries can automatically get
    the array and then there are no extra seeks, the format is well
    defined, etc.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  5. Re: [PATCH prototype] [0/8] Predictive bitmaps for ELF executables

    On Fri, Mar 21, 2008 at 10:26 AM, Andi Kleen wrote:
    > When would that time be? I cannot think of a single heuristic that would
    > work for both "/bin/true" and a OpenOffice start.


    In both cases the stable state is reached after, say, 4 seconds. It's
    just that true terminates before the time is up. I think something
    like "trace the first N seconds" is a reasonable heuristics.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  6. Re: [PATCH prototype] [0/8] Predictive bitmaps for ELF executables

    On Fri, Mar 21, 2008 at 09:36:51PM -0700, Ulrich Drepper wrote:
    > On Fri, Mar 21, 2008 at 10:26 AM, Andi Kleen wrote:
    > > Concrete suggestions please.

    >
    > I already spelled it out. Add a new program header entry, point it to
    > a bit array large enough to cover all loadable segments.


    Ah that's easy, the program header is already supported in the kernel code
    (PT_PRESENT_BITMAP)

    The additional SHDR is just there for easier testing/migration.
    >
    > It is not worth creating problems with this invalid extension just for


    You still didn't say why it was invalid.

    Anyways I disagree on the value of supporting old binaries. I believe
    it is important.

    -Andi
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  7. Re: [PATCH prototype] [0/8] Predictive bitmaps for ELF executables


    On Sat, 2008-03-22 at 08:17 +0100, Andi Kleen wrote:
    > On Fri, Mar 21, 2008 at 09:36:51PM -0700, Ulrich Drepper wrote:
    > > On Fri, Mar 21, 2008 at 10:26 AM, Andi Kleen wrote:
    > > > Concrete suggestions please.

    > >
    > > I already spelled it out. Add a new program header entry, point it to
    > > a bit array large enough to cover all loadable segments.

    >
    > Ah that's easy, the program header is already supported in the kernel code
    > (PT_PRESENT_BITMAP)
    >
    > The additional SHDR is just there for easier testing/migration.
    > >
    > > It is not worth creating problems with this invalid extension just for

    >
    > You still didn't say why it was invalid.
    >
    > Anyways I disagree on the value of supporting old binaries. I believe
    > it is important.
    >
    > -Andi


    Why not stick the bitmap in an xattr?

    --
    Nicholas Miell

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  8. Re: [PATCH prototype] [0/8] Predictive bitmaps for ELF executables

    > Why not stick the bitmap in an xattr?

    xattrs are too small for potentially large binaries and a mess to manage
    (a lot of tools don't know about them)

    -Andi
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  9. Re: [PATCH prototype] [0/8] Predictive bitmaps for ELF executables


    On Sat, 2008-03-22 at 10:10 +0100, Andi Kleen wrote:
    > > Why not stick the bitmap in an xattr?

    >
    > xattrs are too small for potentially large binaries


    *sigh* this is probably true

    > and a mess to manage (a lot of tools don't know about them)


    At this point in time, all tools that don't support xattrs are
    defective, but this is still probably true.

    I just have an instinctive aversion towards the kernel mucking around in
    ELF objects -- for one thing, you're going to have to blacklist
    cryptographically signed binaries.


    --
    Nicholas Miell

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  10. Re: [PATCH prototype] [0/8] Predictive bitmaps for ELF executables

    On Sat, Mar 22, 2008 at 03:16:31AM -0700, Nicholas Miell wrote:
    >
    > *sigh* this is probably true


    Actually it is a relatively weak argument assuming the standard
    4k xattrs, but still an issue.

    The other stronger argument against it is that larger xattrs tend to be
    outside the inode so you would have another seek again.

    > > and a mess to manage (a lot of tools don't know about them)

    >
    > At this point in time, all tools that don't support xattrs are
    > defective,


    Good joke.

    > I just have an instinctive aversion towards the kernel mucking around in
    > ELF objects -- for one thing, you're going to have to blacklist
    > cryptographically signed binaries.


    What signed binaries?

    Anyways there are two ways to deal with this:

    - Run the executable through a little filter that zeroes the bitmap before
    computing the checksum. That is how rpm -V deals with prelinked binaries which
    have a similar issue. You can probably reuse the scripts from rpm.
    - Disable the pbitmap header before you sign, either by never adding
    one or disabling it by turning the phdr type into a nop (should be very simple)

    -Andi
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  11. Re: [PATCH prototype] [0/8] Predictive bitmaps for ELF executables

    On Sat 2008-03-22 15:29:49, Andi Kleen wrote:
    > On Sat, Mar 22, 2008 at 03:16:31AM -0700, Nicholas Miell wrote:
    > >
    > > *sigh* this is probably true

    >
    > Actually it is a relatively weak argument assuming the standard
    > 4k xattrs, but still an issue.
    >
    > The other stronger argument against it is that larger xattrs tend to be
    > outside the inode so you would have another seek again.
    >
    > > > and a mess to manage (a lot of tools don't know about them)

    > >
    > > At this point in time, all tools that don't support xattrs are
    > > defective,

    >
    > Good joke.
    >
    > > I just have an instinctive aversion towards the kernel mucking around in
    > > ELF objects -- for one thing, you're going to have to blacklist
    > > cryptographically signed binaries.

    >
    > What signed binaries?
    >
    > Anyways there are two ways to deal with this:
    >
    > - Run the executable through a little filter that zeroes the bitmap before
    > computing the checksum. That is how rpm -V deals with prelinked binaries which
    > have a similar issue. You can probably reuse the scripts from rpm.


    Is this good idea? Attacker can send you binary with the bitmap
    inverted, it is now slow on your system and signature matches.

    ....might be important for benchmarks... 'here, see, Oracle is slow.
    Feel free to verify the signature'.

    ....ok, I guess it is not too serious, because it is similar to
    fragmentation....
    --
    (english) http://www.livejournal.com/~pavelmachek
    (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pav...rses/blog.html
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  12. Re: [PATCH prototype] [0/8] Predictive bitmaps for ELF executables

    > Is this good idea? Attacker can send you binary with the bitmap
    > inverted, it is now slow on your system and signature matches.


    The first run will fix up any missing bits in the bitmap. Right
    now it cannot get rid of unnecessary pages though unless you
    disable early_fault.

    > ...might be important for benchmarks... 'here, see, Oracle is slow.
    > Feel free to verify the signature'.
    >
    > ...ok, I guess it is not too serious, because it is similar to
    > fragmentation....


    It is actually far better than fragmentation because the bitmap
    loader does IO always in big chunks -- not much seeking will go on.
    The only problem is some wasted mmeory and more IO bandwidth
    usage (but typically binaries are not bigger than a few MB so
    it's not too dramatic)

    So in summary I don't think it's an issue.

    -Andi
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  13. Re: [PATCH prototype] [0/8] Predictive bitmaps for ELF executables

    On Sat, Mar 22, 2008 at 2:10 AM, Andi Kleen wrote:
    > > Why not stick the bitmap in an xattr?

    >
    > xattrs are too small for potentially large binaries and a mess to manage
    > (a lot of tools don't know about them)


    It does not matter a bit whether any other tool know about the xattrs.
    Binaries will not change after they are created to require changing
    the attributes. And it is no problem to not back the data up etc.
    One really doesn't want to waste these resources.

    And as far as the size limitation is concerned. It depends on the
    limit, which I don't know off hand. But really, really big binaries
    don't have to be treated like this anyway. They are not started
    frequently enough to justify this.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  14. Re: [PATCH prototype] [0/8] Predictive bitmaps for ELF executables


    On Sun, 2008-03-23 at 21:20 -0700, Ulrich Drepper wrote:
    > On Sat, Mar 22, 2008 at 2:10 AM, Andi Kleen wrote:
    > > > Why not stick the bitmap in an xattr?

    > >
    > > xattrs are too small for potentially large binaries and a mess to manage
    > > (a lot of tools don't know about them)

    >
    > It does not matter a bit whether any other tool know about the xattrs.
    > Binaries will not change after they are created to require changing
    > the attributes. And it is no problem to not back the data up etc.
    > One really doesn't want to waste these resources.


    Actually, yeah, the tools issue is a bit of a red herring now that you
    mention it -- the only thing that's going to create and use these
    bitmaps is the kernel, and if bitmap gets lost due to the use of ancient
    tools, the kernel will just recreate the bitmap the next time the binary
    runs.

    > And as far as the size limitation is concerned. It depends on the
    > limit, which I don't know off hand. But really, really big binaries
    > don't have to be treated like this anyway. They are not started
    > frequently enough to justify this.


    The limit is filesystem dependent -- I think ext2/3s is something like
    4k total for attribute names and values per inode.

    That's more than enough space for the largest executable on my system
    (emacs at 36788160 bytes) which would have a 1123 byte predictive bitmap
    (plus space for the name e.g. "system.predictive_bitmap"). The bitmap
    also could be compressed.

    --
    Nicholas Miell

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  15. Re: [PATCH prototype] [0/8] Predictive bitmaps for ELF executables


    First emacs is still a rather small executable, there are much larger
    ones around.

    > The limit is filesystem dependent -- I think ext2/3s is something like
    > 4k total for attribute names and values per inode.


    That large xattrs tend to be out of line on a separate block and that would cost
    an additional seek. It would be unlikely to be continuous to the rest of the file
    data and thus even be worse than the SHDR which is at least likely to be
    served from the same track buffer as the executable.

    -Andi
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  16. Re: [PATCH prototype] [0/8] Predictive bitmaps for ELF executables

    On Sun, Mar 23, 2008 at 10:16 PM, Nicholas Miell wrote:
    > The limit is filesystem dependent -- I think ext2/3s is something like
    > 4k total for attribute names and values per inode.
    >
    > That's more than enough space for the largest executable on my system
    > (emacs at 36788160 bytes) which would have a 1123 byte predictive bitmap
    > (plus space for the name e.g. "system.predictive_bitmap"). The bitmap
    > also could be compressed.


    4k attribute means support for about 32768 pages. That's a total of
    134MB. I think this qualifies as sufficient. Also, I assume the
    attribute limit is just a "because nobody needed more so far" limit
    and could in theory be extended.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  17. Re: [PATCH prototype] [0/8] Predictive bitmaps for ELF executables


    On Mon, 2008-03-24 at 12:42 -0700, Ulrich Drepper wrote:
    > On Sun, Mar 23, 2008 at 10:16 PM, Nicholas Miell wrote:
    > > The limit is filesystem dependent -- I think ext2/3s is something like
    > > 4k total for attribute names and values per inode.
    > >
    > > That's more than enough space for the largest executable on my system
    > > (emacs at 36788160 bytes) which would have a 1123 byte predictive bitmap
    > > (plus space for the name e.g. "system.predictive_bitmap"). The bitmap
    > > also could be compressed.

    >
    > 4k attribute means support for about 32768 pages. That's a total of
    > 134MB. I think this qualifies as sufficient. Also, I assume the
    > attribute limit is just a "because nobody needed more so far" limit
    > and could in theory be extended.


    The on-disk format theoretically supports multi-block xattrs, but the
    kernel driver is hardcoded to support only one.

    Also, keep in mind that that 4k limit is for all attributes for an inode
    and includes xattr names, values, and various bits of meta data. As
    such, the limit is actually less than 4k total and the space is shared
    among POSIX ACLs, SELinux contexts and whatever other attributes the
    user would like to store on the file.

    (Actually, it's 4k plus whatever xattr space there is in the inode,
    which depends on how the filesystem was formatted.)

    --
    Nicholas Miell

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  18. Re: [PATCH prototype] [0/8] Predictive bitmaps for ELF executables

    On Mon, Mar 24, 2008 at 12:42:14PM -0700, Ulrich Drepper wrote:
    > On Sun, Mar 23, 2008 at 10:16 PM, Nicholas Miell wrote:
    > > The limit is filesystem dependent -- I think ext2/3s is something like
    > > 4k total for attribute names and values per inode.
    > >
    > > That's more than enough space for the largest executable on my system
    > > (emacs at 36788160 bytes) which would have a 1123 byte predictive bitmap
    > > (plus space for the name e.g. "system.predictive_bitmap"). The bitmap
    > > also could be compressed.

    >
    > 4k attribute means support for about 32768 pages. That's a total of
    > 134MB. I think this qualifies as sufficient. Also, I assume the
    > attribute limit is just a "because nobody needed more so far" limit
    > and could in theory be extended.


    There is still the additional seek. Large xattrs tend to be out of line
    from the inode.

    -Andi
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  19. Re: [PATCH prototype] [0/8] Predictive bitmaps for ELF executables

    On Sun 2008-03-23 18:08:27, Andi Kleen wrote:
    > > Is this good idea? Attacker can send you binary with the bitmap
    > > inverted, it is now slow on your system and signature matches.

    >
    > The first run will fix up any missing bits in the bitmap. Right
    > now it cannot get rid of unnecessary pages though unless you
    > disable early_fault.
    >
    > > ...might be important for benchmarks... 'here, see, Oracle is slow.
    > > Feel free to verify the signature'.
    > >
    > > ...ok, I guess it is not too serious, because it is similar to
    > > fragmentation....

    >
    > It is actually far better than fragmentation because the bitmap
    > loader does IO always in big chunks -- not much seeking will go on.
    > The only problem is some wasted mmeory and more IO bandwidth
    > usage (but typically binaries are not bigger than a few MB so
    > it's not too dramatic)
    >
    > So in summary I don't think it's an issue.


    Agreed.

    --
    (english) http://www.livejournal.com/~pavelmachek
    (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pav...rses/blog.html
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  20. Re: [PATCH prototype] [0/8] Predictive bitmaps for ELF executables

    On Tue, Mar 25, 2008 at 12:54 AM, Andi Kleen wrote:
    > There is still the additional seek.


    You've been proposing and implementing a solution which needs an
    additional seek. Don't use double standards.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast