llvm dev - Feb 2015 - [LLVMdev] IR extension proposal: bitset constants

On Sat, Jan 31, 2015 at 02:53:40PM -0800, JF Bastien
wrote:
> >
> > > The one think we need to ensure is that your metadata can be
dropped by
> > the
> > > optimizer and the code remains correct. I'm guessing no
vtable would mean
> > > anything goes (not check)? That's bad security-wise, but
it'll at least
> > > work. We may want to make sure nothing gets dropped through a
debug flag,
> > > so that we can compile Chrome and be confident that all the
checks we
> > want
> > > are there.
> >
> > So the flag would determine whether no bitset present means return 1
or
> > return 0? Sounds reasonable.
> 
> 
> I'd keep it generating the same code, but have a debug output when the
> debug flag is on. My reasoning is that this wouldn't happen if your
feature
> were a first-class IR construct, but because it's in the
let's-try-it-out
> metadata phase it needs to "just work" when metadata is dropped.
Yours
> being a security-oriented feature we'd want to be able to sanity-check
that
> things compiled as expected for users who care (like Chrome). Once the
> feature graduates to IR instead of metadata it would be expected to always
> be correct security-wise (never silently drop information).
Okay, makes sense.
> Or maybe I'm being overly cautious when it comes to metadata's
ability to
> be dropped?
As far as I am aware, only instruction-level metadata can be dropped entirely.
Module-level metadata stays mostly intact, but references to globals in
metadata can be replaced with nulls if the global is dropped.

The current behavior suits our purposes, but I can't find anywhere where any
of
this behavior is specified, and it's entirely possible that it may change.
The
flag that you propose would be a useful guard against that possibility.

Thanks,
-- 
Peter

Sent from my iPhone
> On Jan 31, 2015, at 4:43 PM, Peter Collingbourne <peter at pcc.me.uk>
wrote:
> 
>> On Sat, Jan 31, 2015 at 02:53:40PM -0800, JF Bastien wrote:
>>>> 
>>>> The one think we need to ensure is that your metadata can be
dropped by
>>> the
>>>> optimizer and the code remains correct. I'm guessing no
vtable would mean
>>>> anything goes (not check)? That's bad security-wise, but
it'll at least
>>>> work. We may want to make sure nothing gets dropped through a
debug flag,
>>>> so that we can compile Chrome and be confident that all the
checks we
>>> want
>>>> are there.
>>> 
>>> So the flag would determine whether no bitset present means return
1 or
>>> return 0? Sounds reasonable.
>> 
>> 
>> I'd keep it generating the same code, but have a debug output when
the
>> debug flag is on. My reasoning is that this wouldn't happen if your
feature
>> were a first-class IR construct, but because it's in the
let's-try-it-out
>> metadata phase it needs to "just work" when metadata is
dropped. Yours
>> being a security-oriented feature we'd want to be able to
sanity-check that
>> things compiled as expected for users who care (like Chrome). Once the
>> feature graduates to IR instead of metadata it would be expected to
always
>> be correct security-wise (never silently drop information).
> 
> Okay, makes sense.
> 
>> Or maybe I'm being overly cautious when it comes to metadata's
ability to
>> be dropped?
> 
> As far as I am aware, only instruction-level metadata can be dropped
entirely.
> Module-level metadata stays mostly intact, but references to globals in
> metadata can be replaced with nulls if the global is dropped.
> 
> The current behavior suits our purposes, but I can't find anywhere
where any of
> this behavior is specified, and it's entirely possible that it may
change. The
> flag that you propose would be a useful guard against that possibility.
I think too much would break if global named metadata just start being dropped.
So for now at least it's fair to expect it's there.

For the global variables it would be fair to add them to the llvm.compiler.used
list if you want to keep them around. Anyone opting in to the bitsets it likely
ok with a few extra globals lasting until link time.

Thanks
Pete
> 
> Thanks,
> -- 
> Peter
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

On Sat, Jan 31, 2015 at 05:57:14PM -0800, Pete Cooper
wrote:
> 
> 
> Sent from my iPhone
> 
> > On Jan 31, 2015, at 4:43 PM, Peter Collingbourne <peter at
pcc.me.uk> wrote:
> > 
> >> On Sat, Jan 31, 2015 at 02:53:40PM -0800, JF Bastien wrote:
> >>>> 
> >>>> The one think we need to ensure is that your metadata can
be dropped by
> >>> the
> >>>> optimizer and the code remains correct. I'm guessing
no vtable would mean
> >>>> anything goes (not check)? That's bad security-wise,
but it'll at least
> >>>> work. We may want to make sure nothing gets dropped
through a debug flag,
> >>>> so that we can compile Chrome and be confident that all
the checks we
> >>> want
> >>>> are there.
> >>> 
> >>> So the flag would determine whether no bitset present means
return 1 or
> >>> return 0? Sounds reasonable.
> >> 
> >> 
> >> I'd keep it generating the same code, but have a debug output
when the
> >> debug flag is on. My reasoning is that this wouldn't happen if
your feature
> >> were a first-class IR construct, but because it's in the
let's-try-it-out
> >> metadata phase it needs to "just work" when metadata is
dropped. Yours
> >> being a security-oriented feature we'd want to be able to
sanity-check that
> >> things compiled as expected for users who care (like Chrome). Once
the
> >> feature graduates to IR instead of metadata it would be expected
to always
> >> be correct security-wise (never silently drop information).
> > 
> > Okay, makes sense.
> > 
> >> Or maybe I'm being overly cautious when it comes to
metadata's ability to
> >> be dropped?
> > 
> > As far as I am aware, only instruction-level metadata can be dropped
entirely.
> > Module-level metadata stays mostly intact, but references to globals
in
> > metadata can be replaced with nulls if the global is dropped.
> > 
> > The current behavior suits our purposes, but I can't find anywhere
where any of
> > this behavior is specified, and it's entirely possible that it may
change. The
> > flag that you propose would be a useful guard against that
possibility.
> I think too much would break if global named metadata just start being
dropped. So for now at least it's fair to expect it's there.
> 
> For the global variables it would be fair to add them to the
llvm.compiler.used list if you want to keep them around. Anyone opting in to the
bitsets it likely ok with a few extra globals lasting until link time.
Okay, sounds good. (FWIW, I don't think it is necessary to keep the vtable
globals around. In fact, all the better if globaldce can eliminate them,
so we can avoid allocating space for them in the bitset.)

I've updated http://reviews.llvm.org/D7288 with the new version of the
implementation that uses the metadata format I proposed earlier.

Thanks,
-- 
Peter