RE: Linking libgcj, and Java security

["Boehm, Hans" <hans_boehm at hp dot com>]

In terms of usability, I would still like to see one of two alternatives:

1) C/C++ statics are scanned by default.  Libgcj itself (and ideally libc) excludes sections that we know don't need to be scanned.  

2) C/C++ statics are not scanned by default, and the CNI spec states they won't be scanned.  Java roots are explicitly registered.  But there is a debug option to enable scanning of all statics up to address <N>, so that you can find the ones you forgot to register.  This should also handle the CNI code that took advantage of the status quo.

Unlike the current situation, I think it should be possible to get the root size down to something reasonable in either case.

I would have preferred (1), but it looks like that's hard to implement well, and nobody is working on it.  The hard part of (2) is getting all the Java roots registered, which I think is being worked on?  Unfortunately, if we insist on the debug mode (which I think we should), this still means we need to be able to find the main data segment in the presence of -Bsymbolic, though it's perhaps less objectionable to rely on /proc to do so.

It doesn't look very hard to get this info from /proc/self/maps.  (Look for a writable mapping of /proc/self/exe (the data segment).  Extend it to include later contiguous anonymous maps (the bss segment).)  But it's not the cleanest thing in the world to rely on that.  Now if we could get the crt0 code to just store these things in suitable globals ...

Hans

> -----Original Message-----
> From: Tom Tromey [mailto:tromey@redhat.com]
> Sent: Wednesday, December 04, 2002 3:51 PM
> To: Boehm, Hans
> Cc: 'Anthony Green'; Andrew Haley; Jeff Sturm; java@gcc.gnu.org
> Subject: Re: Linking libgcj, and Java security
> 
> 
> >>>>> "Hans" == Boehm, Hans <hans_boehm@hp.com> writes:
> 
> Hans> Do we all agree on what the CNI rules are about pointers to
> Hans> collectable objects in C/C++ data structures/libraries?
> 
> Historically they've been fine in globals, but not elsewhere.
> This was probably a mistake to support.
> 
> I don't know how much CNI code is out there, so I don't know the cost
> of changing this.
> 
> Tom
>