Killing The Android libselinux Fork (available)

Killing The Android libselinux Fork (available)

[William Roberts]

So I have been working the last couple of days to understand what it
would take to kill external/libselinux (the Android Fork) and fixup
upstream so most of the delta is in. The only thing we would keep on
the Android side, is android.c and .h. Since those files are self
contained, we should just be able to merge upstream without concerns
of conflict. If we really wanted to, we could spin off a separate
libselinux-android that builds those two files and links to
libselinux, but that seems overkill IMHO.

The work is available here:
https://github.com/williamcroberts/selinux/tree/fork-kill

Currently to Build:
1. remove external/libselinux
2. apply this patch to bionic if not present:
https://android-review.googlesource.com/#/c/276918
3. either set external/selinux to my fork-kill branch or merge selinux
upstream master into external/selinux and apply the two patches listed
below:

Patches that matter ( I don't know how to make pretty little git summaries):

commit e017f48acd2791a6aa62b4ed0c0b44256b26651f
Author: William Roberts <william.c.roberts@intel.com>
Date:   Wed Sep 21 16:06:37 2016 -0700
libselinux: add The Android fork files

commit f40d7facbcaf1337f37b5630b98806fd25b1dbf9
Author: William Roberts <william.c.roberts@intel.com>
Date:   Wed Sep 21 16:00:34 2016 -0700
libselinux: rectify the Android fork

The goal would be to upstream commit f40d7facb and leave
commit e017f48ac on the Android tree.

I am going to do some further testing tomorrow, and plan on submitting
the upstream patch f40d7facbc on Monday. If anyone wants to leave
preliminary feedback, or has a specific thing they want tested, let me know.

Currently tested on the emulator and checked that the digest mechanism for
last restorecon value is working.

-- 
Respectfully,

William C Roberts

Re: Killing The Android libselinux Fork (available)

[William Roberts]

On Thu, Sep 22, 2016 at 6:34 PM, William Roberts
<bill.c.roberts@gmail.com> wrote:
> So I have been working the last couple of days to understand what it
> would take to kill external/libselinux (the Android Fork) and fixup
> upstream so most of the delta is in. The only thing we would keep on
> the Android side, is android.c and .h. Since those files are self
> contained, we should just be able to merge upstream without concerns
> of conflict. If we really wanted to, we could spin off a separate
> libselinux-android that builds those two files and links to
> libselinux, but that seems overkill IMHO.
>
> The work is available here:
> https://github.com/williamcroberts/selinux/tree/fork-kill
>
> Currently to Build:
> 1. remove external/libselinux
> 2. apply this patch to bionic if not present:
> https://android-review.googlesource.com/#/c/276918
> 3. either set external/selinux to my fork-kill branch or merge selinux
> upstream master into external/selinux and apply the two patches listed
> below:
>
> Patches that matter ( I don't know how to make pretty little git summaries):
>
> commit e017f48acd2791a6aa62b4ed0c0b44256b26651f
> Author: William Roberts <william.c.roberts@intel.com>
> Date:   Wed Sep 21 16:06:37 2016 -0700
> libselinux: add The Android fork files
>
> commit f40d7facbcaf1337f37b5630b98806fd25b1dbf9
> Author: William Roberts <william.c.roberts@intel.com>
> Date:   Wed Sep 21 16:00:34 2016 -0700
> libselinux: rectify the Android fork
>
> The goal would be to upstream commit f40d7facb and leave
> commit e017f48ac on the Android tree.
>
> I am going to do some further testing tomorrow, and plan on submitting
> the upstream patch f40d7facbc on Monday. If anyone wants to leave
> preliminary feedback, or has a specific thing they want tested, let me know.
>
> Currently tested on the emulator and checked that the digest mechanism for
> last restorecon value is working.
>
> --
> Respectfully,
>
> William C Roberts

FYI I may rebase that branch at anytime... you have been warned :-P

Re: Killing The Android libselinux Fork (available)

[Jeffrey Vander Stoep]

[-- Attachment #1: Type: text/plain, Size: 2432 bytes --]

Remember to test on the Mac build. About a year ago I moved the host side
tools over to upstream libselinux, but had to revert because it broke the
Mac build in multiple places. Since then Richard Haines has done a lot of
work to reduce the diff between upstream and the Android fork. Hopefully
that will reduce your effort.

On Thu, Sep 22, 2016 at 6:39 PM William Roberts <bill.c.roberts@gmail.com>
wrote:

On Thu, Sep 22, 2016 at 6:34 PM, William Roberts
<bill.c.roberts@gmail.com> wrote:
> So I have been working the last couple of days to understand what it
> would take to kill external/libselinux (the Android Fork) and fixup
> upstream so most of the delta is in. The only thing we would keep on
> the Android side, is android.c and .h. Since those files are self
> contained, we should just be able to merge upstream without concerns
> of conflict. If we really wanted to, we could spin off a separate
> libselinux-android that builds those two files and links to
> libselinux, but that seems overkill IMHO.
>
> The work is available here:
> https://github.com/williamcroberts/selinux/tree/fork-kill
>
> Currently to Build:
> 1. remove external/libselinux
> 2. apply this patch to bionic if not present:
> https://android-review.googlesource.com/#/c/276918
> 3. either set external/selinux to my fork-kill branch or merge selinux
> upstream master into external/selinux and apply the two patches listed
> below:
>
> Patches that matter ( I don't know how to make pretty little git
summaries):
>
> commit e017f48acd2791a6aa62b4ed0c0b44256b26651f
> Author: William Roberts <william.c.roberts@intel.com>
> Date:   Wed Sep 21 16:06:37 2016 -0700
> libselinux: add The Android fork files
>
> commit f40d7facbcaf1337f37b5630b98806fd25b1dbf9
> Author: William Roberts <william.c.roberts@intel.com>
> Date:   Wed Sep 21 16:00:34 2016 -0700
> libselinux: rectify the Android fork
>
> The goal would be to upstream commit f40d7facb and leave
> commit e017f48ac on the Android tree.
>
> I am going to do some further testing tomorrow, and plan on submitting
> the upstream patch f40d7facbc on Monday. If anyone wants to leave
> preliminary feedback, or has a specific thing they want tested, let me
know.
>
> Currently tested on the emulator and checked that the digest mechanism for
> last restorecon value is working.
>
> --
> Respectfully,
>
> William C Roberts

FYI I may rebase that branch at anytime... you have been warned :-P

[-- Attachment #2: Type: text/html, Size: 4624 bytes --]

Re: Killing The Android libselinux Fork (available)

[William Roberts]

[-- Attachment #1: Type: text/plain, Size: 2766 bytes --]

On Sep 22, 2016 9:18 PM, "Jeffrey Vander Stoep" <jeffv@google.com> wrote:
>
> Remember to test on the Mac build. About a year ago I moved the host side
tools over to upstream libselinux, but had to revert because it broke the
Mac build in multiple places. Since then Richard Haines has done a lot of
work to reduce the diff between upstream and the Android fork. Hopefully
that will reduce your effort.

Yeah I'm quite concerned about the Mac build, does anyone on here have
access to a Mac for testing?

>
> On Thu, Sep 22, 2016 at 6:39 PM William Roberts <bill.c.roberts@gmail.com>
wrote:
>>
>> On Thu, Sep 22, 2016 at 6:34 PM, William Roberts
>> <bill.c.roberts@gmail.com> wrote:
>> > So I have been working the last couple of days to understand what it
>> > would take to kill external/libselinux (the Android Fork) and fixup
>> > upstream so most of the delta is in. The only thing we would keep on
>> > the Android side, is android.c and .h. Since those files are self
>> > contained, we should just be able to merge upstream without concerns
>> > of conflict. If we really wanted to, we could spin off a separate
>> > libselinux-android that builds those two files and links to
>> > libselinux, but that seems overkill IMHO.
>> >
>> > The work is available here:
>> > https://github.com/williamcroberts/selinux/tree/fork-kill
>> >
>> > Currently to Build:
>> > 1. remove external/libselinux
>> > 2. apply this patch to bionic if not present:
>> > https://android-review.googlesource.com/#/c/276918
>> > 3. either set external/selinux to my fork-kill branch or merge selinux
>> > upstream master into external/selinux and apply the two patches listed
>> > below:
>> >
>> > Patches that matter ( I don't know how to make pretty little git
summaries):
>> >
>> > commit e017f48acd2791a6aa62b4ed0c0b44256b26651f
>> > Author: William Roberts <william.c.roberts@intel.com>
>> > Date:   Wed Sep 21 16:06:37 2016 -0700
>> > libselinux: add The Android fork files
>> >
>> > commit f40d7facbcaf1337f37b5630b98806fd25b1dbf9
>> > Author: William Roberts <william.c.roberts@intel.com>
>> > Date:   Wed Sep 21 16:00:34 2016 -0700
>> > libselinux: rectify the Android fork
>> >
>> > The goal would be to upstream commit f40d7facb and leave
>> > commit e017f48ac on the Android tree.
>> >
>> > I am going to do some further testing tomorrow, and plan on submitting
>> > the upstream patch f40d7facbc on Monday. If anyone wants to leave
>> > preliminary feedback, or has a specific thing they want tested, let me
know.
>> >
>> > Currently tested on the emulator and checked that the digest mechanism
for
>> > last restorecon value is working.
>> >
>> > --
>> > Respectfully,
>> >
>> > William C Roberts
>>
>> FYI I may rebase that branch at anytime... you have been warned :-P

[-- Attachment #2: Type: text/html, Size: 3984 bytes --]

Re: Killing The Android libselinux Fork (available)

[Joshua Brindle]

William Roberts wrote:
> On Sep 22, 2016 9:18 PM, "Jeffrey Vander Stoep"<jeffv@google.com>  wrote:
>> Remember to test on the Mac build. About a year ago I moved the host side
> tools over to upstream libselinux, but had to revert because it broke the
> Mac build in multiple places. Since then Richard Haines has done a lot of
> work to reduce the diff between upstream and the Android fork. Hopefully
> that will reduce your effort.
>
> Yeah I'm quite concerned about the Mac build, does anyone on here have
> access to a Mac for testing?

I do, let me know when you have a branch you need looked at and I'll try 
to get to it.


>
>> On Thu, Sep 22, 2016 at 6:39 PM William Roberts<bill.c.roberts@gmail.com>
> wrote:
>>> On Thu, Sep 22, 2016 at 6:34 PM, William Roberts
>>> <bill.c.roberts@gmail.com>  wrote:
>>>> So I have been working the last couple of days to understand what it
>>>> would take to kill external/libselinux (the Android Fork) and fixup
>>>> upstream so most of the delta is in. The only thing we would keep on
>>>> the Android side, is android.c and .h. Since those files are self
>>>> contained, we should just be able to merge upstream without concerns
>>>> of conflict. If we really wanted to, we could spin off a separate
>>>> libselinux-android that builds those two files and links to
>>>> libselinux, but that seems overkill IMHO.
>>>>
>>>> The work is available here:
>>>> https://github.com/williamcroberts/selinux/tree/fork-kill
>>>>
>>>> Currently to Build:
>>>> 1. remove external/libselinux
>>>> 2. apply this patch to bionic if not present:
>>>> https://android-review.googlesource.com/#/c/276918
>>>> 3. either set external/selinux to my fork-kill branch or merge selinux
>>>> upstream master into external/selinux and apply the two patches listed
>>>> below:
>>>>
>>>> Patches that matter ( I don't know how to make pretty little git
> summaries):
>>>> commit e017f48acd2791a6aa62b4ed0c0b44256b26651f
>>>> Author: William Roberts<william.c.roberts@intel.com>
>>>> Date:   Wed Sep 21 16:06:37 2016 -0700
>>>> libselinux: add The Android fork files
>>>>
>>>> commit f40d7facbcaf1337f37b5630b98806fd25b1dbf9
>>>> Author: William Roberts<william.c.roberts@intel.com>
>>>> Date:   Wed Sep 21 16:00:34 2016 -0700
>>>> libselinux: rectify the Android fork
>>>>
>>>> The goal would be to upstream commit f40d7facb and leave
>>>> commit e017f48ac on the Android tree.
>>>>
>>>> I am going to do some further testing tomorrow, and plan on submitting
>>>> the upstream patch f40d7facbc on Monday. If anyone wants to leave
>>>> preliminary feedback, or has a specific thing they want tested, let me
> know.
>>>> Currently tested on the emulator and checked that the digest mechanism
> for
>>>> last restorecon value is working.
>>>>
>>>> --
>>>> Respectfully,
>>>>
>>>> William C Roberts
>>> FYI I may rebase that branch at anytime... you have been warned :-P
>
> _______________________________________________
> Seandroid-list mailing list
> Seandroid-list@tycho.nsa.gov
> To unsubscribe, send email to Seandroid-list-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to Seandroid-list-request@tycho.nsa.gov.

Re: Killing The Android libselinux Fork (available)

[William Roberts]

On Fri, Sep 23, 2016 at 6:57 AM, Joshua Brindle
<brindle@quarksecurity.com> wrote:
> William Roberts wrote:
>>
>> On Sep 22, 2016 9:18 PM, "Jeffrey Vander Stoep"<jeffv@google.com>  wrote:
>>>
>>> Remember to test on the Mac build. About a year ago I moved the host side
>>
>> tools over to upstream libselinux, but had to revert because it broke the
>> Mac build in multiple places. Since then Richard Haines has done a lot of
>> work to reduce the diff between upstream and the Android fork. Hopefully
>> that will reduce your effort.
>>
>> Yeah I'm quite concerned about the Mac build, does anyone on here have
>> access to a Mac for testing?
>
>
> I do, let me know when you have a branch you need looked at and I'll try to
> get to it.

Feel free to test the fork-kill branch from my github, you should find
the details
below from a previous message in the thread.

<snip>

>>>>> The work is available here:
>>>>> https://github.com/williamcroberts/selinux/tree/fork-kill
>>>>>
>>>>> Currently to Build:
>>>>> 1. remove external/libselinux
>>>>> 2. apply this patch to bionic if not present:
>>>>> https://android-review.googlesource.com/#/c/276918
>>>>> 3. either set external/selinux to my fork-kill branch or merge selinux
>>>>> upstream master into external/selinux and apply the two patches listed
>>>>> below:
>>>>>
>>>>> Patches that matter ( I don't know how to make pretty little git
>>
>> summaries):
>>>>>
>>>>> commit e017f48acd2791a6aa62b4ed0c0b44256b26651f
>>>>> Author: William Roberts<william.c.roberts@intel.com>
>>>>> Date:   Wed Sep 21 16:06:37 2016 -0700
>>>>> libselinux: add The Android fork files
>>>>>
>>>>> commit f40d7facbcaf1337f37b5630b98806fd25b1dbf9
>>>>> Author: William Roberts<william.c.roberts@intel.com>
>>>>> Date:   Wed Sep 21 16:00:34 2016 -0700
>>>>> libselinux: rectify the Android fork
>>>>>
>>>>> The goal would be to upstream commit f40d7facb and leave
>>>>> commit e017f48ac on the Android tree.
>>>>>
>>>>> I am going to do some further testing tomorrow, and plan on submitting
>>>>> the upstream patch f40d7facbc on Monday. If anyone wants to leave
>>>>> preliminary feedback, or has a specific thing they want tested, let me
>>

<snip>

Re: Killing The Android libselinux Fork (available)

[William Roberts]

In case anyone is following, Stephen provided some early feedback here:
https://github.com/williamcroberts/selinux/commit/f40d7facbcaf1337f37b5630b98806fd25b1dbf9#diff-ee9fed90a923eef67184cd34ffbb2a9cR551

As promised, the fork was rebased and force pushed.

On Thu, Sep 22, 2016 at 6:39 PM, William Roberts
<bill.c.roberts@gmail.com> wrote:
> On Thu, Sep 22, 2016 at 6:34 PM, William Roberts
> <bill.c.roberts@gmail.com> wrote:
>> So I have been working the last couple of days to understand what it
>> would take to kill external/libselinux (the Android Fork) and fixup
>> upstream so most of the delta is in. The only thing we would keep on
>> the Android side, is android.c and .h. Since those files are self
>> contained, we should just be able to merge upstream without concerns
>> of conflict. If we really wanted to, we could spin off a separate
>> libselinux-android that builds those two files and links to
>> libselinux, but that seems overkill IMHO.
>>
>> The work is available here:
>> https://github.com/williamcroberts/selinux/tree/fork-kill
>>
>> Currently to Build:
>> 1. remove external/libselinux
>> 2. apply this patch to bionic if not present:
>> https://android-review.googlesource.com/#/c/276918
>> 3. either set external/selinux to my fork-kill branch or merge selinux
>> upstream master into external/selinux and apply the two patches listed
>> below:
>>
>> Patches that matter ( I don't know how to make pretty little git summaries):
>>
>> commit e017f48acd2791a6aa62b4ed0c0b44256b26651f
>> Author: William Roberts <william.c.roberts@intel.com>
>> Date:   Wed Sep 21 16:06:37 2016 -0700
>> libselinux: add The Android fork files
>>
>> commit f40d7facbcaf1337f37b5630b98806fd25b1dbf9
>> Author: William Roberts <william.c.roberts@intel.com>
>> Date:   Wed Sep 21 16:00:34 2016 -0700
>> libselinux: rectify the Android fork
>>
>> The goal would be to upstream commit f40d7facb and leave
>> commit e017f48ac on the Android tree.
>>
>> I am going to do some further testing tomorrow, and plan on submitting
>> the upstream patch f40d7facbc on Monday. If anyone wants to leave
>> preliminary feedback, or has a specific thing they want tested, let me know.
>>
>> Currently tested on the emulator and checked that the digest mechanism for
>> last restorecon value is working.
>>
>> --
>> Respectfully,
>>
>> William C Roberts
>
> FYI I may rebase that branch at anytime... you have been warned :-P



-- 
Respectfully,

William C Roberts

Re: Killing The Android libselinux Fork (available)

[Joshua Brindle]

William Roberts wrote:
> On Fri, Sep 23, 2016 at 6:57 AM, Joshua Brindle
> <brindle@quarksecurity.com>  wrote:
>> William Roberts wrote:
>>> On Sep 22, 2016 9:18 PM, "Jeffrey Vander Stoep"<jeffv@google.com>   wrote:
>>>> Remember to test on the Mac build. About a year ago I moved the host side
>>> tools over to upstream libselinux, but had to revert because it broke the
>>> Mac build in multiple places. Since then Richard Haines has done a lot of
>>> work to reduce the diff between upstream and the Android fork. Hopefully
>>> that will reduce your effort.
>>>
>>> Yeah I'm quite concerned about the Mac build, does anyone on here have
>>> access to a Mac for testing?
>>
>> I do, let me know when you have a branch you need looked at and I'll try to
>> get to it.
>
> Feel free to test the fork-kill branch from my github, you should find
> the details
> below from a previous message in the thread.
>

Sure,

Mac uses llvm which seems to catch much more than gcc, I have to get rid 
of Werror to even get partially through a build. First issues:

genbools.c:71:9: warning: unused variable 'size' [-Wunused-variable]
         size_t size = 0;
                ^
1 warning generated.
cc -Wall -W -Wundef -Wshadow -Wmissing-format-attribute -O2 -I. 
-I../include -D_GNU_SOURCE -I../cil/include -fPIC -c -o genusers.o 
genusers.c
genusers.c:39:9: warning: unused variable 'len' [-Wunused-variable]
         size_t len = 0;
                ^
genusers.c:63:14: warning: variable 'nread' is uninitialized when used 
here [-Wuninitialized]
                 if (buffer[nread - 1] == '\n')
                            ^~~~~
genusers.c:40:15: note: initialize the variable 'nread' to silence this 
warning
         ssize_t nread;
                      ^
                       = 0

but the .symver actually kills it altogether (I get a lot of these):

<inline asm>:10:1: error: unknown directive
.symver cil_filecons_to_string_nopdb, cil_filecons_to_string@@LIBSEPOL_1.1
^

Re: Killing The Android libselinux Fork (available)

[William Roberts]

[-- Attachment #1: Type: text/plain, Size: 2262 bytes --]

On Sep 23, 2016 13:01, "Joshua Brindle" <brindle@quarksecurity.com> wrote:
>
> William Roberts wrote:
>>
>> On Fri, Sep 23, 2016 at 6:57 AM, Joshua Brindle
>> <brindle@quarksecurity.com>  wrote:
>>>
>>> William Roberts wrote:
>>>>
>>>> On Sep 22, 2016 9:18 PM, "Jeffrey Vander Stoep"<jeffv@google.com>
 wrote:
>>>>>
>>>>> Remember to test on the Mac build. About a year ago I moved the host
side
>>>>
>>>> tools over to upstream libselinux, but had to revert because it broke
the
>>>> Mac build in multiple places. Since then Richard Haines has done a lot
of
>>>> work to reduce the diff between upstream and the Android fork.
Hopefully
>>>> that will reduce your effort.
>>>>
>>>> Yeah I'm quite concerned about the Mac build, does anyone on here have
>>>> access to a Mac for testing?
>>>
>>>
>>> I do, let me know when you have a branch you need looked at and I'll
try to
>>> get to it.
>>
>>
>> Feel free to test the fork-kill branch from my github, you should find
>> the details
>> below from a previous message in the thread.
>>
>
> Sure,
>
> Mac uses llvm which seems to catch much more than gcc, I have to get rid
of Werror to even get partially through a build. First issues:

Thanks Josh, I'll look at these and prep patches. Weird Android builds with
clang,
I wonder why it's not catching some of these.

>
> genbools.c:71:9: warning: unused variable 'size' [-Wunused-variable]
>         size_t size = 0;
>                ^
> 1 warning generated.
> cc -Wall -W -Wundef -Wshadow -Wmissing-format-attribute -O2 -I.
-I../include -D_GNU_SOURCE -I../cil/include -fPIC -c -o genusers.o
genusers.c
> genusers.c:39:9: warning: unused variable 'len' [-Wunused-variable]
>         size_t len = 0;
>                ^
> genusers.c:63:14: warning: variable 'nread' is uninitialized when used
here [-Wuninitialized]
>                 if (buffer[nread - 1] == '\n')
>                            ^~~~~
> genusers.c:40:15: note: initialize the variable 'nread' to silence this
warning
>         ssize_t nread;
>                      ^
>                       = 0
>
> but the .symver actually kills it altogether (I get a lot of these):
>
> <inline asm>:10:1: error: unknown directive
> .symver cil_filecons_to_string_nopdb, cil_filecons_to_string@@LIBSEPOL_1.1
> ^
>

[-- Attachment #2: Type: text/html, Size: 3266 bytes --]

Re: Killing The Android libselinux Fork (available)

[Joshua Brindle]

William Roberts wrote:
<snip>
>
> Thanks Josh, I'll look at these and prep patches. Weird Android builds with
> clang,
> I wonder why it's not catching some of these.
>

Not sure, for reference the version installed here is :

Apple LLVM version 8.0.0 (clang-800.0.38)

Re: Killing The Android libselinux Fork (available)

[Stephen Smalley]

On 09/23/2016 04:01 PM, Joshua Brindle wrote:
> William Roberts wrote:
>> On Fri, Sep 23, 2016 at 6:57 AM, Joshua Brindle
>> <brindle@quarksecurity.com>  wrote:
>>> William Roberts wrote:
>>>> On Sep 22, 2016 9:18 PM, "Jeffrey Vander Stoep"<jeffv@google.com>  
>>>> wrote:
>>>>> Remember to test on the Mac build. About a year ago I moved the
>>>>> host side
>>>> tools over to upstream libselinux, but had to revert because it
>>>> broke the
>>>> Mac build in multiple places. Since then Richard Haines has done a
>>>> lot of
>>>> work to reduce the diff between upstream and the Android fork.
>>>> Hopefully
>>>> that will reduce your effort.
>>>>
>>>> Yeah I'm quite concerned about the Mac build, does anyone on here have
>>>> access to a Mac for testing?
>>>
>>> I do, let me know when you have a branch you need looked at and I'll
>>> try to
>>> get to it.
>>
>> Feel free to test the fork-kill branch from my github, you should find
>> the details
>> below from a previous message in the thread.
>>
> 
> Sure,
> 
> Mac uses llvm which seems to catch much more than gcc, I have to get rid
> of Werror to even get partially through a build. First issues:
> 
> genbools.c:71:9: warning: unused variable 'size' [-Wunused-variable]
>         size_t size = 0;
>                ^
> 1 warning generated.
> cc -Wall -W -Wundef -Wshadow -Wmissing-format-attribute -O2 -I.
> -I../include -D_GNU_SOURCE -I../cil/include -fPIC -c -o genusers.o
> genusers.c
> genusers.c:39:9: warning: unused variable 'len' [-Wunused-variable]
>         size_t len = 0;
>                ^
> genusers.c:63:14: warning: variable 'nread' is uninitialized when used
> here [-Wuninitialized]
>                 if (buffer[nread - 1] == '\n')
>                            ^~~~~
> genusers.c:40:15: note: initialize the variable 'nread' to silence this
> warning
>         ssize_t nread;
>                      ^
>                       = 0
> 
> but the .symver actually kills it altogether (I get a lot of these):
> 
> <inline asm>:10:1: error: unknown directive
> .symver cil_filecons_to_string_nopdb, cil_filecons_to_string@@LIBSEPOL_1.1
> ^

Are you building this in the context of Android?  We disable the symver
stuff automatically if ANDROID is defined.  We only need to ensure that
the portion of selinux userspace that is compiled for Android builds on
MacOS X; it will never fully build there.

Re: Killing The Android libselinux Fork (available)

[William Roberts]

On Fri, Sep 23, 2016 at 1:24 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> On 09/23/2016 04:01 PM, Joshua Brindle wrote:
>> William Roberts wrote:
>>> On Fri, Sep 23, 2016 at 6:57 AM, Joshua Brindle
>>> <brindle@quarksecurity.com>  wrote:
>>>> William Roberts wrote:
>>>>> On Sep 22, 2016 9:18 PM, "Jeffrey Vander Stoep"<jeffv@google.com>
>>>>> wrote:
>>>>>> Remember to test on the Mac build. About a year ago I moved the
>>>>>> host side
>>>>> tools over to upstream libselinux, but had to revert because it
>>>>> broke the
>>>>> Mac build in multiple places. Since then Richard Haines has done a
>>>>> lot of
>>>>> work to reduce the diff between upstream and the Android fork.
>>>>> Hopefully
>>>>> that will reduce your effort.
>>>>>
>>>>> Yeah I'm quite concerned about the Mac build, does anyone on here have
>>>>> access to a Mac for testing?
>>>>
>>>> I do, let me know when you have a branch you need looked at and I'll
>>>> try to
>>>> get to it.
>>>
>>> Feel free to test the fork-kill branch from my github, you should find
>>> the details
>>> below from a previous message in the thread.
>>>
>>
>> Sure,
>>
>> Mac uses llvm which seems to catch much more than gcc, I have to get rid
>> of Werror to even get partially through a build. First issues:
>>
>> genbools.c:71:9: warning: unused variable 'size' [-Wunused-variable]
>>         size_t size = 0;
>>                ^
>> 1 warning generated.
>> cc -Wall -W -Wundef -Wshadow -Wmissing-format-attribute -O2 -I.
>> -I../include -D_GNU_SOURCE -I../cil/include -fPIC -c -o genusers.o
>> genusers.c
>> genusers.c:39:9: warning: unused variable 'len' [-Wunused-variable]
>>         size_t len = 0;
>>                ^
>> genusers.c:63:14: warning: variable 'nread' is uninitialized when used
>> here [-Wuninitialized]
>>                 if (buffer[nread - 1] == '\n')
>>                            ^~~~~
>> genusers.c:40:15: note: initialize the variable 'nread' to silence this
>> warning
>>         ssize_t nread;
>>                      ^
>>                       = 0
>>
>> but the .symver actually kills it altogether (I get a lot of these):
>>
>> <inline asm>:10:1: error: unknown directive
>> .symver cil_filecons_to_string_nopdb, cil_filecons_to_string@@LIBSEPOL_1.1
>> ^
>
> Are you building this in the context of Android?  We disable the symver
> stuff automatically if ANDROID is defined.  We only need to ensure that
> the portion of selinux userspace that is compiled for Android builds on
> MacOS X; it will never fully build there.
>

All those files belong to libsepol, which I am pretty sure is building on Mac.
However, size is unused on __APPLE__ path, so I will prep patches for those
unused and uninitialized variables.

I am mostly concerned about libselinux, which on Android we only use a subset
of the files. It would be possible to have a Makefile setup with the
files and defines
but it would only build the build host version and not the target. The
target would
be trickier as it links and builds against bionic.

-- 
Respectfully,

William C Roberts

Re: Killing The Android libselinux Fork (available)

[William Roberts]

I am quite happy to report that what's on the current fork-kill branch on github
libselinux builds on mac with no warnings. Also, we want the libsepol
patches upstream to
cleanse those warnings as well.

All the smaller patches have been sent out and merged, with the exception of
"libselinux: drop unused stdio_ext.h header file", which was just sent
out. I don't
expect an issue on that merge.

This leaves:
https://github.com/williamcroberts/selinux/commit/df022f0f4425498f8537cc2c73064b6bb37c6a05
will be whats needed  upstream to close the gap. I think we might want to
take a revertme patch that comments out all the libselinux build
files, so when it's merged into
aosp theirs no duplicate definitions of libselinux, and then once they
can revert that commit,
we can do the same. They will likely have a window where they can
fetch upstream into external/selinux
before killing external/libselinux and enabling the build files. This
seems to be the approach last
time with a blank toplevel Android.mk

sds let me know how you want the afformentioned commit on the link
above broken up if at all, or any other
issues you  have, and Ill prep the final patch series for the mailing list.

Thanks all for the input provided, and Josh for your late night mac help!

On Fri, Sep 23, 2016 at 1:44 PM, William Roberts
<bill.c.roberts@gmail.com> wrote:
> On Fri, Sep 23, 2016 at 1:24 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
>> On 09/23/2016 04:01 PM, Joshua Brindle wrote:
>>> William Roberts wrote:
>>>> On Fri, Sep 23, 2016 at 6:57 AM, Joshua Brindle
>>>> <brindle@quarksecurity.com>  wrote:
>>>>> William Roberts wrote:
>>>>>> On Sep 22, 2016 9:18 PM, "Jeffrey Vander Stoep"<jeffv@google.com>
>>>>>> wrote:
>>>>>>> Remember to test on the Mac build. About a year ago I moved the
>>>>>>> host side
>>>>>> tools over to upstream libselinux, but had to revert because it
>>>>>> broke the
>>>>>> Mac build in multiple places. Since then Richard Haines has done a
>>>>>> lot of
>>>>>> work to reduce the diff between upstream and the Android fork.
>>>>>> Hopefully
>>>>>> that will reduce your effort.
>>>>>>
>>>>>> Yeah I'm quite concerned about the Mac build, does anyone on here have
>>>>>> access to a Mac for testing?
>>>>>
>>>>> I do, let me know when you have a branch you need looked at and I'll
>>>>> try to
>>>>> get to it.
>>>>
>>>> Feel free to test the fork-kill branch from my github, you should find
>>>> the details
>>>> below from a previous message in the thread.
>>>>
>>>
>>> Sure,
>>>
>>> Mac uses llvm which seems to catch much more than gcc, I have to get rid
>>> of Werror to even get partially through a build. First issues:
>>>
>>> genbools.c:71:9: warning: unused variable 'size' [-Wunused-variable]
>>>         size_t size = 0;
>>>                ^
>>> 1 warning generated.
>>> cc -Wall -W -Wundef -Wshadow -Wmissing-format-attribute -O2 -I.
>>> -I../include -D_GNU_SOURCE -I../cil/include -fPIC -c -o genusers.o
>>> genusers.c
>>> genusers.c:39:9: warning: unused variable 'len' [-Wunused-variable]
>>>         size_t len = 0;
>>>                ^
>>> genusers.c:63:14: warning: variable 'nread' is uninitialized when used
>>> here [-Wuninitialized]
>>>                 if (buffer[nread - 1] == '\n')
>>>                            ^~~~~
>>> genusers.c:40:15: note: initialize the variable 'nread' to silence this
>>> warning
>>>         ssize_t nread;
>>>                      ^
>>>                       = 0
>>>
>>> but the .symver actually kills it altogether (I get a lot of these):
>>>
>>> <inline asm>:10:1: error: unknown directive
>>> .symver cil_filecons_to_string_nopdb, cil_filecons_to_string@@LIBSEPOL_1.1
>>> ^
>>
>> Are you building this in the context of Android?  We disable the symver
>> stuff automatically if ANDROID is defined.  We only need to ensure that
>> the portion of selinux userspace that is compiled for Android builds on
>> MacOS X; it will never fully build there.
>>
>
> All those files belong to libsepol, which I am pretty sure is building on Mac.
> However, size is unused on __APPLE__ path, so I will prep patches for those
> unused and uninitialized variables.
>
> I am mostly concerned about libselinux, which on Android we only use a subset
> of the files. It would be possible to have a Makefile setup with the
> files and defines
> but it would only build the build host version and not the target. The
> target would
> be trickier as it links and builds against bionic.
>
> --
> Respectfully,
>
> William C Roberts



-- 
Respectfully,

William C Roberts