Mailing List Archive

'pax_kernel' USE flag
Dear everyone,

Seeing as in the end this USE flag is not going anywhere in spite of
Gentoo no longer providing PaX-capable kernel sources, could we please
rename it (e.g. to 'pax-kernel') so that it no longer contains a
disallowed character. I understand the main reason this hasn't been done
yet is that we expected it might disappear altogether.

--
Marecki
Re: 'pax_kernel' USE flag [ In reply to ]
On Tue, 2021-06-22 at 10:35 +0100, Marek Szuba wrote:
> Dear everyone,
>
> Seeing as in the end this USE flag is not going anywhere in spite of
> rename it (e.g. to 'pax-kernel') so that it no longer contains a
> disallowed character. I understand the main reason this hasn't been
> done
> yet is that we expected it might disappear altogether.

+1, I like it, let's do it. I consider the tradeoff in this case much
for renaming it, given that the userbase will be minute (compared to say
the python targets).
Re: 'pax_kernel' USE flag [ In reply to ]
>>>>> On Tue, 22 Jun 2021, Marek Szuba wrote:

> Seeing as in the end this USE flag is not going anywhere in spite of
> Gentoo no longer providing PaX-capable kernel sources, could we please
> rename it (e.g. to 'pax-kernel') so that it no longer contains a
> disallowed character. I understand the main reason this hasn't been
> done yet is that we expected it might disappear altogether.

+1 for renaming to pax-kernel.

A related question, the pax_kernel flag is still used by these packages:

app-emulation/virtualbox
app-emulation/virtualbox-modules
dev-java/icedtea
dev-lang/mlton
dev-lang/mono
dev-lang/smlnj
dev-libs/libffi
dev-libs/libffi-compat
media-sound/spotify
net-libs/nodejs

From my past experience with PaX support in Emacs, things used to break
on a regular basis [1]. So I wonder, how is the status of PaX support in
the packages listed above? Do their maintainers actually test them with
a PaX kernel (which would be a third-party kernel, I suppose)? If not,
maybe the flag should be removed from these untested packages?

Ulrich

[1] https://archives.gentoo.org/gentoo-dev/message/4b5000ef34b506e536b7841ffa17aa39
Re: 'pax_kernel' USE flag [ In reply to ]
On Tue, Jun 22, 2021 at 12:06 PM Ulrich Mueller <ulm@gentoo.org> wrote:
>
> >>>>> On Tue, 22 Jun 2021, Marek Szuba wrote:
>
> > Seeing as in the end this USE flag is not going anywhere in spite of
> > Gentoo no longer providing PaX-capable kernel sources, could we please
> > rename it (e.g. to 'pax-kernel') so that it no longer contains a
> > disallowed character. I understand the main reason this hasn't been
> > done yet is that we expected it might disappear altogether.
>
> +1 for renaming to pax-kernel.
>
> A related question, the pax_kernel flag is still used by these packages:
>
> app-emulation/virtualbox
> app-emulation/virtualbox-modules
> dev-java/icedtea
> dev-lang/mlton
> dev-lang/mono
> dev-lang/smlnj
> dev-libs/libffi
> dev-libs/libffi-compat
> media-sound/spotify
> net-libs/nodejs
>
> From my past experience with PaX support in Emacs, things used to break
> on a regular basis [1]. So I wonder, how is the status of PaX support in
> the packages listed above? Do their maintainers actually test them with
> a PaX kernel (which would be a third-party kernel, I suppose)? If not,
> maybe the flag should be removed from these untested packages?

ebuild maintainers are rarely responsible for the PaX-related
workarounds that end up in ebuilds. A better question would be if
*anybody* is using these packages with a PaX-enabled kernel, and
that's more difficult to answer.
Re: 'pax_kernel' USE flag [ In reply to ]
On Tue, 22 Jun 2021 10:35:12 +0100
Marek Szuba <marecki@gentoo.org> wrote:

> Dear everyone,
>
> Seeing as in the end this USE flag is not going anywhere in spite of
> Gentoo no longer providing PaX-capable kernel sources, could we please
> rename it (e.g. to 'pax-kernel') so that it no longer contains a
> disallowed character. I understand the main reason this hasn't been done
> yet is that we expected it might disappear altogether.

Just renaming pax_kernel to pax-kernel for dev-libs/libffi will likely
brick a system on W^X kernel on first world update. python will
probably start crashing instantly. Unless user explicitly notices that
they need to enable a new flag.

Other packages should be less problematic to just switch over.

One of the steps forward for libffi would be to add extra USE=pax-kernel
with REQUIRED_USE="pax_kernel? ( pax-kernel )" or 'die' equivalent.

The specifics should ideally be handled by hardened@ team. Otherwise we
can do 'use pax_kernel || die' libffi experiment if nobody objects. Say,
in a few days.

--

Sergei
Re: 'pax_kernel' USE flag [ In reply to ]
FYI:

The PaX community in Gentoo is still big and active.

Many Gentoo users received free access to upstream sources or became
paying customers.

It's just not available for everyone for free/without registration
anymore. But it is still a thing in Gentoo.


> So I wonder, how is the status of PaX support in
> the packages listed above?

I can only speak for icedtea and nodejs which are working fine.


--
Regards,
Thomas Deutschmann / Gentoo Linux Developer
fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5
Re: 'pax_kernel' USE flag [ In reply to ]
On Tue, Jun 22, 2021 at 3:19 PM Thomas Deutschmann <whissi@gentoo.org> wrote:
> The PaX community in Gentoo is still big and active.
>
> Many Gentoo users received free access to upstream sources or became
> paying customers.
>
> It's just not available for everyone for free/without registration
> anymore. But it is still a thing in Gentoo.

Can you substantiate that claim?

There was a pax-kernel USE flag on Mesa and I don't recall anyone
saying a word when I removed it.

If there are paying customers that have PaX kernels, perhaps they'd be
interested in providing some support for Gentoo if we're being asked
to retain support for something we cannot test.
Re: 'pax_kernel' USE flag [ In reply to ]
On Wed, 2021-06-23 at 00:19 +0200, Thomas Deutschmann wrote:
> The PaX community in Gentoo is still big and active.

Do you have any evidence to prove that? The activity on PaX-related
bugs seems to disagree with you. A 'big and active' community should
probably result in many patches and fixed bugs, shouldn't it?

> Many Gentoo users received free access to upstream sources or became
> paying customers.

How many? Is it actually such a large number to claim that
the community is 'big'? I suppose that in the past PaX users might have
been a significant subset of Gentoo users but not today.

> It's just not available for everyone for free/without registration
> anymore. But it is still a thing in Gentoo.

Your comment makes it sounds like 'just registering' is an option.
The website seems to disagree with that, pretty clearly saying it's
a yearly subscription. How much? They don't say but it's reasonable to
assume it's a steep price. Wouldn't be surprised if people are
forbidden from saying.

But even if they offered me a free copy I wouldn't take it. They have
violated the principles of GPL and harmed the FLOSS world. If you care
about open source, you wouldn't pay them a broken penny. If you do, you
just support their actions and soon enough more GPL projects will figure
out that they can steal all their contributions and declare themselves
'keep paying and do not share the code as GPL permits you to'.

Let's not forget that their patches are generally 'pure garbage' sold as
'extra secure' [1].

Now, how is all of that even relevant to the topic at hand? Are you
saying that because you have a grsec subscription, you're actually going
to help out with something? Or just complain when things get in the way
of people who don't have one and who don't care the slightest bit?
>

[1] https://www.spinics.net/lists/kernel/msg2540934.html

--
Best regards,
Micha? Górny
Re: 'pax_kernel' USE flag [ In reply to ]
>>>>> On Wed, 23 Jun 2021, Micha? Górny wrote:

>> It's just not available for everyone for free/without registration
>> anymore. But it is still a thing in Gentoo.

> Your comment makes it sounds like 'just registering' is an option.
> The website seems to disagree with that, pretty clearly saying it's
> a yearly subscription. How much? They don't say but it's reasonable to
> assume it's a steep price. Wouldn't be surprised if people are
> forbidden from saying.

Apparently it was $17k per year, in 2016:
https://mail.gnu.org/archive/html/libreplanet-discuss/2016-05/msg00114.html

> But even if they offered me a free copy I wouldn't take it. They have
> violated the principles of GPL and harmed the FLOSS world. If you care
> about open source, you wouldn't pay them a broken penny. If you do, you
> just support their actions and soon enough more GPL projects will figure
> out that they can steal all their contributions and declare themselves
> 'keep paying and do not share the code as GPL permits you to'.

This has been discussed at length, and I don't think we need to
reiterate it here.

My point was that most developers cannot test if the pax_kernel flag in
a given package does what it should. IMHO the consequence is that we
can no longer consider PaX a supported configuration.

Ulrich
Re: 'pax_kernel' USE flag [ In reply to ]
On 2021-06-22 19:01, Sergei Trofimovich wrote:

> One of the steps forward for libffi would be to add extra USE=pax-kernel
> with REQUIRED_USE="pax_kernel? ( pax-kernel )" or 'die' equivalent.

Sounds like a good idea to me, that way people who don't pay attention
to news items will notice.

--
Marecki
Re: 'pax_kernel' USE flag [ In reply to ]
> > The PaX community in Gentoo is still big and active.
> >
> > Many Gentoo users received free access to upstream sources or became
> > paying customers.
> >
> > It's just not available for everyone for free/without registration
> > anymore. But it is still a thing in Gentoo.
>
> Can you substantiate that claim?
>
> There was a pax-kernel USE flag on Mesa and I don't recall anyone
> saying a word when I removed it.
>
> If there are paying customers that have PaX kernels, perhaps they'd be
> interested in providing some support for Gentoo if we're being asked
> to retain support for something we cannot test.

Summary from the replies so far:
* either noone is using it,
* or noone is willing to admit using it.

--
Andreas K. H?ttel
dilfridge@gentoo.org
Gentoo Linux developer
(council, toolchain, base-system, perl, libreoffice)
Re: 'pax_kernel' USE flag [ In reply to ]
On Wed, 23 Jun 2021 10:46:00 +0100
Marek Szuba <marecki@gentoo.org> wrote:

> On 2021-06-22 19:01, Sergei Trofimovich wrote:
>
> > One of the steps forward for libffi would be to add extra USE=pax-kernel
> > with REQUIRED_USE="pax_kernel? ( pax-kernel )" or 'die' equivalent.
>
> Sounds like a good idea to me, that way people who don't pay attention
> to news items will notice.

It's now part of libffi-3.4_rc1:

# If you are USE=pax_kernel user you really want USE=pax-kernel as well.
# That's a flag rename: https://archives.gentoo.org/gentoo-dev/message/273f5ec9ebc8075f6ee8d8cdda9e759e
REQUIRED_USE="pax_kernel? ( pax-kernel )"

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0b2c89773e0df20c0c770b6d8620564b76468578

--

Sergei
Re: 'pax_kernel' USE flag [ In reply to ]
On 2021-06-22 10:35, Marek Szuba wrote:

> Seeing as in the end this USE flag is not going anywhere in spite of
> Gentoo no longer providing PaX-capable kernel sources, could we please
> rename it (e.g. to 'pax-kernel') so that it no longer contains a
> disallowed character.

Done. Now the old name only persists in dev-libs/libffi owing to the
compatibility guard proposed by slyfox, and I'd say it should be removed
even from there in a month.

--
Marecki
Re: 'pax_kernel' USE flag [ In reply to ]
On Tue, Jun 22, 2021 at 11:43 PM Matt Turner <mattst88@gentoo.org> wrote:
>
> On Tue, Jun 22, 2021 at 3:19 PM Thomas Deutschmann <whissi@gentoo.org> wrote:
> > The PaX community in Gentoo is still big and active.
> >
> > Many Gentoo users received free access to upstream sources or became
> > paying customers.
> >
> > It's just not available for everyone for free/without registration
> > anymore. But it is still a thing in Gentoo.
>
> Can you substantiate that claim?
>
> There was a pax-kernel USE flag on Mesa and I don't recall anyone
> saying a word when I removed it.
>
> If there are paying customers that have PaX kernels, perhaps they'd be
> interested in providing some support for Gentoo if we're being asked
> to retain support for something we cannot test.

I'd still like an answer to any of this.
Re: 'pax_kernel' USE flag [ In reply to ]
On 2021-06-23 08:43, Matt Turner wrote:
> On Tue, Jun 22, 2021 at 3:19 PM Thomas Deutschmann <whissi@gentoo.org> wrote:
>> The PaX community in Gentoo is still big and active.
>>
>> Many Gentoo users received free access to upstream sources or became
>> paying customers.
>>
>> It's just not available for everyone for free/without registration
>> anymore. But it is still a thing in Gentoo.
>
> Can you substantiate that claim?

I am probably not the right person to answer that, given that I was
never active in Gentoo's hardened/PaX project but let me try: When I got
in touch with that stuff (via Debian) and was looking for help, I always
run into a community full of helpful Gentoo users.

The project itself always had a very good connection with the Gentoo
project. Before they stopped providing unrestricted access, the Gentoo
PaX/hardened community was around ~30 *active* people with additional
~40-60 changing people hanging around which I believe is a lot for such
a niche.

That's why upstream also mentioned Gentoo in
https://grsecurity.net/passing_the_baton.php.

Regarding numbers: I am not sure what you are expecting. All I can tell
you is that people who were active, interested and probably known to
upstream had the chance to get free access for their personal use (there
was even an offer for Gentoo infrastructure...). I don't know how many
are still using Gentoo.


> There was a pax-kernel USE flag on Mesa and I don't recall anyone
> saying a word when I removed it.

As you probably know, I am not a Linux desktop user (yet). My complete
experience with that PaX stuff is limited to servers.


> If there are paying customers that have PaX kernels, perhaps they'd be
> interested in providing some support for Gentoo if we're being asked
> to retain support for something we cannot test.

Yeah, would be nice to hear something from Gentoo hardened project at
all (I am looking at you, mschiff, zorry or blueness ;)). I think
slashbeast could also provide more information.

I still remember when I reworked firefox/thunderbird ebuild and broke
PaX marking there (https://bugs.gentoo.org/756679). So yes, we have at
least some users ;-)


--
Regards,
Thomas Deutschmann / Gentoo Linux Developer
fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5
Re: 'pax_kernel' USE flag [ In reply to ]
On Tue, Jul 6, 2021 at 7:41 PM Thomas Deutschmann <whissi@gentoo.org> wrote:
> As you probably know, I am not a Linux desktop user (yet). My complete
> experience with that PaX stuff is limited to servers.

Maybe I've misunderstood what you meant. You don't use Linux on the desktop?

But, you maintain Firefox? I'm definitely confused :)
Re: 'pax_kernel' USE flag [ In reply to ]
On 2021-07-07 05:05, Matt Turner wrote:
> On Tue, Jul 6, 2021 at 7:41 PM Thomas Deutschmann <whissi@gentoo.org> wrote:
>> As you probably know, I am not a Linux desktop user (yet). My complete
>> experience with that PaX stuff is limited to servers.
>
> Maybe I've misunderstood what you meant. You don't use Linux on the desktop?
>
> But, you maintain Firefox? I'm definitely confused :)

No, I became Firefox maintainer by accident via security project when
former devs weren't available and I started to help out.

I actually bought a notebook a few years ago just to be able to do more
testing (I have a lot of experience with Selenium where I am using the
browser in headless mode but when you want to improve desktop
integration...). This also enabled me to become a test user for leio's
GNOME 3.30 work which was a great experience.

My Gentoo desktop usage has increased a lot since then but Linux still
isn't my *primary* desktop platform (yet).


--
Regards,
Thomas Deutschmann / Gentoo Linux Developer
fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5