Re: e10s-multi update and tests

[bowen]

On Thursday, 23 March 2017 01:01:16 UTC, Nicholas Nethercote  wrote:
> Do we have a clear definition of "content process"? I.e. does/will it
> include:
> 
> - GMP processes (no?)
> - GPU process (probably not?)
> - file:// URL processes (probably should?)
> - Web Extensions processes (probably should?)
> - ServiceWorker processes (probably should?)

Each content process type (remote type) has its own pool of processes.
Remote types at the moment are: web (the normal content process), file, 
extension and webLargeAllocation.
GMP and GPU are their own GeckoProcessType.
(I'm not sure how the ServiceWorker one fits into this.)

Currently the pref dom.ipc.processCount acts as the default if 
dom.ipc.processCount. is not set.
(Mainly because this pref was already being used by a number of people, perhaps 
it should just have been left as a fallback for dom.ipc.processCount.web)

Current pref settings:
 * dom.ipc.processCount : 1 (Nightly 4)
 * dom.ipc.processCount.extension : 1
 * dom.ipc.processCount.webLargeAllocation : 10

So, on Nightly the web and file processes will both use up to 4 processes.
The file:// URL process is probably a fairly special case (although I don't 
have any stats on its usage), so we should probably add a specific setting of 1 
for that.

Maybe that 4 should be set on dom.ipc.processCount.web instead.

There has also been talk of setting an overall maximum although you would 
always have to allow at least 1 of each to start, even if we were at the 
maximum.

Cheers,
Bob

> Thanks.
> 
> Nick
> 
> On Thu, Mar 23, 2017 at 10:45 AM, Blake Kaplan  wrote:
> 
> > Hello all,
> >
> > As some of you might have noticed, we are now defaulting to 4 content
> > processes on Nightly builds! We're continuing to collect data and
> > planning on running experiments with different numbers of processes to
> > generate more data and allow us to fine-tune our defaults and
> > strategies for process allocation.
> >
> > As part of our effort to enable e10s-multi on Nightly, we disabled a
> > few tests that were misbehaving. We've re-enabled most of them and are
> > on track to finish re-enabling them (after verifying that the problem
> > was in the test and not the underlying code).
> >
> > As we get to the end of that effort, I'd like to ask everybody to
> > think about any areas that they feel are not tested with multiple
> > content processes that should be. Obviously, as we find regressions
> > related to multiple content processes we'll add regression tests, but
> > I would like to avoid having any last-minute panics over missing
> > tests.
> >
> > Thanks.
> > --
> > Blake
> > ___
> > firefox-dev mailing list
> > firefox-...@mozilla.org
> > https://mail.mozilla.org/listinfo/firefox-dev
> >

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Enabling filesystem read-restrictions for content process sandbox

[bowen]

As a follow-up to this, tomorrow's (2017-07-22) Nightly will have this enabled 
for the Windows content process sandbox as well.

On Windows this removes access that the User gains via their own SID.
So generally things under their home directory (C:\Users\\).
With exceptions for the Firefox installation directory and the chrome directory 
in the profile.

There are a few other restrictions included as well, for example reading and 
writing to the clipboard.

If you hit any issues on Windows after tomorrow that disappear when you set the 
pref security.sandbox.content.level to 2 or lower, please file a bug to block 
https://bugzilla.mozilla.org/show_bug.cgi?id=1366697.

Cheers,
Bob


On Thursday, 6 July 2017 15:07:50 UTC+1, Alex Gaynor  wrote:
> Hi dev-platform,
> 
> On behalf of the Runtime Content Isolation (aka sandboxing) team, I'm
> delighted
> to announce that starting later this week, our macOS and Windows nightly
> builds
> will prohibit read access to most of the filesystem in the content process!
> 
> What does this mean for you? First and foremost, a more secure browser!
> Second,
> it means that if you see bugs, please report them, our goal is to put this
> on
> the trains for 56! If you run into anything, please file it as a blocker for
> https://bugzilla.mozilla.org/show_bug.cgi?id=1377522 .
> 
> Finally, it means that in code you're writing, you should not expect to be
> able
> to read from the filesystem in the content process -- with the exception of
> inside the .app bundle, or in the chrome/ subdirectory of the profile
> directory.
> 
> If you need access to a file in content, you should plan on remoting that
> to the
> parent process. When designing these APIs, please be careful to ensure the
> parent process is able to perform appropriate permissions checks such that
> the
> IPC mechanism isn't able to bypass the sandbox's goal of preventing a
> malicious
> content process from accessing the entire file system.
> 
> This represents the culmination of a lot of work by a lot of folks, both on
> our
> team and on many other teams who helped out with refactoring their code --
> thank
> you!
> 
> We're looking forward to also shipping this for Linux soon.
> 
> Cheers,
> Alex

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

PSA: Making Windows 10 SDK version 10.0.10586 the minimum for building Firefox

[bowen]

Hi,

I'm just about to land a patch that makes Windows 10 SDK version 10.0.10586 the 
minimum required for building Firefox.

We require this to be able to compile certain features for the Chromium Windows 
process sandbox.

If you are using Visual Studio 2015 and you don't have this, it (or a later 
version) can be installed using the Visual Studio installer or from here:
https://developer.microsoft.com/en-us/windows/downloads/sdk-archive

Automation is already using version 10.0.14393.

I've updated:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Windows_Prerequisites

Thanks,
Bob

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

PSA: Making Windows 10 SDK version 10.0.14393 the minimum for building Firefox

[bowen]

Hi,

Early in the 59 cycle, I intend to make Windows 10 SDK version 10.0.14393 the 
minimum required for building Firefox.

Like before, this is because of new Windows security features used in an update 
to the Chromium Windows process sandbox.

If you are using Visual Studio 2015 and you don't have this, it can be 
installed using the Visual Studio installer or from here:
https://developer.microsoft.com/en-us/windows/downloads/sdk-archive

If you are using Visual Studio 2017, you should already have a later version 
installed.
If you haven't, again you can use the Visual Studio installer or download 
directly.

Automation is already using Visual Studio 2017 and SDK version 10.0.15063.

I've already updated the online instructions:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Windows_Prerequisites

Thanks,
Bob 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: Making Windows 10 SDK version 10.0.14393 the minimum for building Firefox

[bowen]

This change is now on mozilla-inbound.

On Thursday, 9 November 2017 10:31:41 UTC, bo...@mozilla.com  wrote:
> Hi,
> 
> Early in the 59 cycle, I intend to make Windows 10 SDK version 10.0.14393 the 
> minimum required for building Firefox.
> 
> Like before, this is because of new Windows security features used in an 
> update to the Chromium Windows process sandbox.
> 
> If you are using Visual Studio 2015 and you don't have this, it can be 
> installed using the Visual Studio installer or from here:
> https://developer.microsoft.com/en-us/windows/downloads/sdk-archive
> 
> If you are using Visual Studio 2017, you should already have a later version 
> installed.
> If you haven't, again you can use the Visual Studio installer or download 
> directly.
> 
> Automation is already using Visual Studio 2017 and SDK version 10.0.15063.
> 
> I've already updated the online instructions:
> https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Windows_Prerequisites
> 
> Thanks,
> Bob

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Hiding 'new' statements - Good or Evil?

[bowen]

I'm not sure what the benefits are (the MakeUnique comments only really seem to 
give aesthetic ones), but they do make it a bit harder when searching through 
code to see where things are constructed.

I suppose if we always stick to using Make* then (with regex) it wouldn't add 
too much burden for searching.

On Thursday, 23 November 2017 07:50:27 UTC, gsqu...@mozilla.com  wrote:
> Should we allow hiding 'new' statements, or keep them as visible as possible?
> 
> 
> Some context:
> Recently in bug 1410252 I added a MakeNotNull(args...) function that does 
> `NotNull(new T(args...))`, in the style of MakeUnique and others. It also 
> works with RefPtr.
> 
> My first goal was to avoid the unnecessary nullptr-check in the NotNull 
> constructor, since our new is infallible by default.
> 
> And I thought that hiding the naked new statement was a nice side benefit, as 
> I was under the impression that it was A Good Thing in modern C++. (Though I 
> think the main reason for that, was to prevent leaks when handling exceptions 
> in multi-allocation expressions, so it doesn't apply to us here.)
> 
> Now, a colleague remarked that this was making the memory allocation less 
> obvious.
> "What about MakeUnique?" I asked; "I'm used to them now" he retorted. :-P
> 
> 
> So, what do you all think?
> - Should I remove MakeNotNull?
> - Or should we allow/encourage more MakeX functions instead of X(new...)? I'm 
> thinking MakeRefPtr might be nice.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: How to pass data from to a content process when it starts up?

[bowen]

Hi Nick,

SandboxBroker::AddHandleToShare was added to add the handles to the sandbox 
policy, before it was realised that we'd need to do this for the non-sandboxed 
process launch as well, hence LaunchOptions::handles_to_inherit.

I think we should change [1] to pass the LaunchOptions and then use them within 
SandboxBroker::LaunchApp to add the handles to the policy and get rid of 
SandboxBroker::AddHandleToShare.

Cheers,
Bob

[1] 
https://searchfox.org/mozilla-central/rev/d03ad8843e3bf2e856126bc53b0475c595e5183b/ipc/glue/GeckoChildProcessHost.cpp#1046

On Wednesday, 14 February 2018 07:02:43 UTC, Nicholas Nethercote  wrote:
> Hi,
> 
> When a content process is started, a bunch of pref values are sent via
> some -intPrefs/-boolPrefs/-stringPrefs arguments on the command line. This
> is
> ugly and limiting and causes multiple problems, so I'd like to find a
> different
> way to send this data.
> 
> The use case is pretty simple, because it's one way data transfer. The
> important thing is that it must happen very early, i.e. before the normal
> IPC
> mechanism gets going.
> 
> I figured shared memory would be a reasonable way to do this, something like
> the following.
> 
> - The parent sets up a shared memory segment, and writes some data to it.
> 
> - The parent spawns the child, and passes identifying information about the
>   shared memory segment to the child (e.g. via the command line).
> 
> - The child gets the shared memory segment identifer, uses it to open the
>   segment, and reads the data.
> 
> - The child disposes of the shared memory segment.
> 
> At first I tried using NSPR's shared memory functions, but they're not used
> anywhere else in Firefox, and they have bugs, and shmget() is blocked by the
> Linux sandbox.
> 
> So then I tried using base::SharedMemory instead, from
> ipc/chromium/src/base/shared_memory.h, basically like this:
> 
> Parent:
> SharedMemory shm;
> shm.Create(name, size);
> shm.Open();
> shm.Map();
> char* p = shm.memory();
> ... write data to p ...
> ... launch child process, passing `name` via cmdline ...
> shm.Unmap();// done automatically when shm is destroyed
> shm.Close();// done automatically when shm is destroyed
> 
> Child:
> ... get `name` from the command line...
> SharedMemory shm;
> shm.Open(name);
> shm.Map();
> char* p = shm.memory();
> ... read data from p ...
> shm.Delete();   // this is a no-op on Windows
> shm.Unmap();// done automatically when shm is destroyed
> shm.Close();// done automatically when shm is destroyed
> 
> This works fine on Unix. If the shared memory file is closed by the parent
> before it's opened by the child, that's ok, because it persists until it is
> explicitly deleted.
> 
> But it doesn't work on Windows. On Windows Delete() does nothing. Instead, a
> file mapping object is auto-deleted when its refcount falls to zero. So if
> the
> parent calls Close() before the child calls Open() -- which happens in
> practice -- then the file mapping object is auto-deleted and the child
> Open()
> fails.
> 
> If I change the parent to heap-allocate `shm` so it's not auto-destroyed at
> the
> end of the function, things work out, but we'll end up with leaks: the
> SharedMemory object, opened file view, the handle, and the file mapping will
> all leak.
> 
> I then tried using SharedMemory::ShareToProcess(), but that requires that
> the
> child process already exist and the parent has its PID, which is a pain.
> 
> I then found this blog post from Raymond Chen:
> https://blogs.msdn.microsoft.com/oldnewthing/20031211-00/?p=41543
> 
> It describes exactly what I want, but it requires using the bInheritHandle
> parameter, which base::SharedMemory doesn't do. I could change it to do so,
> but
> then it looks like I'd need to deal with I then found
> LaunchOptions::handles_to_inherit as well... and at this point I figure it's
> worth asking for help!
> 
> Does anybody have suggestions about the best way to do this? Thanks.
> 
> Nick

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: How to pass data from to a content process when it starts up?

[bowen]

Perhaps we should also change the various GeckoChildProcessHost Launch methods 
to accept LaunchOptions or a similar structure instead of aExtraOpts.

On Wednesday, 14 February 2018 09:23:05 UTC, bo...@mozilla.com  wrote:
> Hi Nick,
> 
> SandboxBroker::AddHandleToShare was added to add the handles to the sandbox 
> policy, before it was realised that we'd need to do this for the 
> non-sandboxed process launch as well, hence LaunchOptions::handles_to_inherit.
> 
> I think we should change [1] to pass the LaunchOptions and then use them 
> within SandboxBroker::LaunchApp to add the handles to the policy and get rid 
> of SandboxBroker::AddHandleToShare.
> 
> Cheers,
> Bob
> 
> [1] 
> https://searchfox.org/mozilla-central/rev/d03ad8843e3bf2e856126bc53b0475c595e5183b/ipc/glue/GeckoChildProcessHost.cpp#1046
> 
> On Wednesday, 14 February 2018 07:02:43 UTC, Nicholas Nethercote  wrote:
> > Hi,
> > 
> > When a content process is started, a bunch of pref values are sent via
> > some -intPrefs/-boolPrefs/-stringPrefs arguments on the command line. This
> > is
> > ugly and limiting and causes multiple problems, so I'd like to find a
> > different
> > way to send this data.
> > 
> > The use case is pretty simple, because it's one way data transfer. The
> > important thing is that it must happen very early, i.e. before the normal
> > IPC
> > mechanism gets going.
> > 
> > I figured shared memory would be a reasonable way to do this, something like
> > the following.
> > 
> > - The parent sets up a shared memory segment, and writes some data to it.
> > 
> > - The parent spawns the child, and passes identifying information about the
> >   shared memory segment to the child (e.g. via the command line).
> > 
> > - The child gets the shared memory segment identifer, uses it to open the
> >   segment, and reads the data.
> > 
> > - The child disposes of the shared memory segment.
> > 
> > At first I tried using NSPR's shared memory functions, but they're not used
> > anywhere else in Firefox, and they have bugs, and shmget() is blocked by the
> > Linux sandbox.
> > 
> > So then I tried using base::SharedMemory instead, from
> > ipc/chromium/src/base/shared_memory.h, basically like this:
> > 
> > Parent:
> > SharedMemory shm;
> > shm.Create(name, size);
> > shm.Open();
> > shm.Map();
> > char* p = shm.memory();
> > ... write data to p ...
> > ... launch child process, passing `name` via cmdline ...
> > shm.Unmap();// done automatically when shm is destroyed
> > shm.Close();// done automatically when shm is destroyed
> > 
> > Child:
> > ... get `name` from the command line...
> > SharedMemory shm;
> > shm.Open(name);
> > shm.Map();
> > char* p = shm.memory();
> > ... read data from p ...
> > shm.Delete();   // this is a no-op on Windows
> > shm.Unmap();// done automatically when shm is destroyed
> > shm.Close();// done automatically when shm is destroyed
> > 
> > This works fine on Unix. If the shared memory file is closed by the parent
> > before it's opened by the child, that's ok, because it persists until it is
> > explicitly deleted.
> > 
> > But it doesn't work on Windows. On Windows Delete() does nothing. Instead, a
> > file mapping object is auto-deleted when its refcount falls to zero. So if
> > the
> > parent calls Close() before the child calls Open() -- which happens in
> > practice -- then the file mapping object is auto-deleted and the child
> > Open()
> > fails.
> > 
> > If I change the parent to heap-allocate `shm` so it's not auto-destroyed at
> > the
> > end of the function, things work out, but we'll end up with leaks: the
> > SharedMemory object, opened file view, the handle, and the file mapping will
> > all leak.
> > 
> > I then tried using SharedMemory::ShareToProcess(), but that requires that
> > the
> > child process already exist and the parent has its PID, which is a pain.
> > 
> > I then found this blog post from Raymond Chen:
> > https://blogs.msdn.microsoft.com/oldnewthing/20031211-00/?p=41543
> > 
> > It describes exactly what I want, but it requires using the bInheritHandle
> > parameter, which base::SharedMemory doesn't do. I could change it to do so,
> > but
> > then it looks like I'd need to deal with I then found
> > LaunchOptions::handles_to_inherit as well... and at this point I figure it's
> > worth asking for help!
> > 
> > Does anybody have suggestions about the best way to do this? Thanks.
> > 
> > Nick

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Windows content process sandbox strengthening.

[bowen]

The next Nightly should include two small improvements to the Windows content 
process sandbox policy.

The new default pref is:
security.sandbox.content.level=2

I have just found a new regression (bug 1211873) since landing this.
This is that file:// URLs for files on network shares are blocked.

The two main existing regressions with level 1 are bugs 1156742 and 1173371.

If this change causes any other new regressions, please file them to block bug 
1207972.

When testing regressions please try the pref at level 1 first and then 0.
If the regression is still there at level 1, but not at 0, file to block bug 
1151767 instead.

Thanks,
Bob
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Updating 32-bit Windows users to 64-bit Windows builds?

[bowen]

On Thursday, 12 May 2016 21:36:53 UTC+1, Chris Peterson  wrote:
> Yes. Flash and Silverlight both have 64-bit plugins that work in 64-bit 
> Firefox. Streaming video services will likely move their Firefox users 
> from Silverlight to Widevine this year, so Silverlight usage will 
> decline by EOY.

As Flash Player doesn't provide Protected Mode for 64-bit, we've enabled our 
own sandbox.
Unfortunately this causes some regressions as the Flash DLL was never designed 
to be sandboxed when run in process like this. We'd like to strengthen the 
policy, but that breaks too many things.

So, we'd have to think carefully before deciding who we could move.
 
> On 5/12/16 1:10 PM, Ryan VanderMeulen wrote:
> > Flash installs the 32-bit and 64-bit plugin versions side by side
> > already (in System32 and SysWOW64, respectively), so I don't think
> > that's an issue here.

Confusingly the 64-bit version lives in System32 and the 32-bit version in 
SysWOW64.
This is Microsoft's confusion not Adobe's.
SysWOW64 generally contains files used for running 32-bit binaries on 64-bit 
Windows (WOW64 is Windows [32-bit] On Windows 64[-bit])
System32 is just a legacy naming hangover as I understand, because too many 
application depended on it.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Separate Content Process for loading file:// URI pages

[bowen]

In bug 1147911, I've just landed patches to enable using a separate content 
process for loading file:// URI content pages.

This is controlled by the pref browser.tabs.remote.separateFileUriProcess and 
this is set to true for Nightly only at the moment.

Please file any issues you find to block bug 1147911.

This should not affect the other internal uses of file:// URI which we still 
have in the content process.

Cheers,
Bob
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to not fix: Building with gcc-4.6 for Fx38+

[bowen]

Hi,

In summary: Officially make gcc-4.7 our minimum supported version. Fx38 and 39 
don't compile with 4.6 and none of the GNU/Linux package maintainers I have 
contacted have any major concerns over dropping it.


There are three outstanding bugs open over Fx38+ not compiling with gcc-4.6.
One of these is to do with an update to the Chromium sandbox code we use, which 
I landed. Chromium have already dropped support for 4.6.
The other two would be fairly easy to fix.

I could back-out parts of my patch to get it compiling with 4.6, but it is 
going to make it difficult to take new versions of the sandbox code.

I've contacted the package maintainers for Debian, Red Hat, openSUSE, SLES and 
Ubuntu and they either don't have a problem with dropping 4.6 or, at least, no 
more of a problem than the fact we've already dropped 4.4.
These distros were picked because they have longer support cycles and tend to 
have some older versions of gcc.

I've also posted to the mozilla-linux-taskforce mailing list.

If nobody has any issues with this, I'll look into sorting the patches to make 
the build failures explicit.

Cheers,
Bob
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to not fix: Building with gcc-4.6 for Fx38+

[bowen]

On Tuesday, March 10, 2015 at 5:06:31 PM UTC, Ehsan Akhgari wrote:

> >> Here's a push in case the bugs don't exist in certain builds:
> >> https://treeherder.mozilla.org/#/jobs?repo=try&revision=044e896fc6fa
> >
> > I was looking at the log for a B2G Device Image build (I think it
> > was the one for Nexus 5-L) a few days (less than a week) ago, and it
> > was using gcc 4.8 for the target and gcc 4.6 for the host (assuming
> > I was reading the logs correctly).
> >
> > I point this out because:
> >
> >   (1) the device image build isn't in that try run, and
> >
> >   (2) it's not clear to me that the compiler version checks check
> >   both the target and host compiler versions when cross-compiling
> 
> That's a good point.  I don't think we have any checks for the host 
> compiler.

I'll admit to knowing nothing about B2G Device Image builds, but I see that 
setting the default host compiler is in the instructions on the MDN B2G build 
instructions [1].
What are the reasons for this?
The Firefox OS instructions [2] seem to suggest this is only needed for older 
versions of B2G.
Are there automated Device Image builders that we will need to get updated?
Do we need to inform partners, who might be using gcc-4.6?

Am I right in thinking that B2G only currently uses up to Gecko 37?
This may explain why we haven't seen a problem, but we might start seeing one 
since a merge a week ago.
If we do a patch (for bug 1134487) is on mozilla-inbound and has been requested 
for uplift to beta.

[1] 
https://developer.mozilla.org/en-US/Firefox_OS/Preparing_for_your_first_B2G_build
[2] 
https://developer.mozilla.org/en-US/Firefox_OS/Firefox_OS_build_prerequisites
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to not fix: Building with gcc-4.6 for Fx38+

[bowen]

On Wednesday, March 11, 2015 at 8:40:46 AM UTC, Mike Hommey wrote:
> On Tue, Mar 10, 2015 at 07:23:36PM -0700, Brian Smith wrote:
> >  wrote:
> > > In summary: Officially make gcc-4.7 our minimum supported version. Fx38 
> > > and 39 don't compile with 4.6 and none of the GNU/Linux package 
> > > maintainers I have contacted have any major concerns over dropping it.
> > 
> > I propose that either:
> > 
> > (1) GCC 4.8 be made the minimum supported version immediately, or

*snip*

> > > I've contacted the package maintainers for Debian, Red Hat, openSUSE, 
> > > SLES and Ubuntu and they either don't have a problem with dropping 4.6 
> > > or, at least, no more of a problem than the fact we've already dropped 
> > > 4.4.
> > 
> > Did any of them state a preference for not going to GCC 4.8? If so,
> > what was the reasoning?
> 
> At least for Debian, current stable can't build security updates with
> more than 4.7.

In addition, as I understand it:
* openSUSE still has supported versions with gcc-4.7
* SLES (on older versions without 4.6 or 4.7) use a special stack of packages 
to build Firefox which includes gcc-4.7
* Ubuntu 12.04 LTS has 4.6, but are happy to build with a later version as long 
as there are no runtime issues
* Older versions of RHEL are still on gcc-4.4, so they are already going to 
have to do something for Fx37 anyway and moving to 4.7 instead of 4.6 would 
probably not cause too much extra pain.

I don't know how much more work moving to gcc-4.8 would cause, but it would 
certainly be some.

Also, from what I can tell of the C++ features that gcc-4.8 enables (from [1]), 
none of them are available until MSVC 2015.
It seems likely that we'll be supporting MSVC 2013 until the next ESR, so I 
don't see that moving to 4.8 gives us any immediate benefits.

[1] https://developer.mozilla.org/en-US/docs/Using_CXX_in_Mozilla_code
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to not fix: Building with gcc-4.6 for Fx38+

[bowen]

On Wednesday, March 11, 2015 at 11:53:11 AM UTC, Brian Smith wrote:
>  wrote:
> > Also, from what I can tell of the C++ features that gcc-4.8 enables (from 
> > [1]), none of them are available until MSVC 2015.
> > It seems likely that we'll be supporting MSVC 2013 until the next ESR, so I 
> > don't see that moving to 4.8 gives us any immediate benefits.
> >
> > [1] https://developer.mozilla.org/en-US/docs/Using_CXX_in_Mozilla_code
> 
> ESR is also an incredibly wasteful drag on Mozilla development. When
> ESR was first proposed we agreed, as far as I understand, that we
> would NOT hold back improvements to the real Firefox for the sake of
> ESR. In fact, it is counterproductive to hold back changes like this
> for ESR's benefit because doing so makes it *harder* to backport
> changes to ESR. For example, imagine if you had updated the Chromium
> code after the next ESR branched, and then 12 months later a serious
> and hard-to-fix security bug in the old Chromium code was found*. It
> would be much less work to backport the patch is the minimum compiler
> version for ESR was as similar to the minimum compiler version for
> real Firefox.

Right, that's sort of the point I was trying (and probably failing) to make.
Given that we (and probably Chromium) would be unlikely to drop MSVC 2013 
before our next ESR anyway, then a complex security fix that used new c++ 
features is less likely.
Unless the fix were in code only compiled with gcc, in which case we'd need to 
move to gcc-4.8 and look at alternatives for ESR.

Moving to 4.8 now gives us no new features and causes at least some work for 
maintainers and from what I can tell, work to upgrade some of our build systems.

If the policy is to not hold back improvements for the sake of ESR then the 
corollary to that should be that we don't push for changes in the ESR version 
just to protect it later.

I'll be happy to help move us to 4.8 or later when we are looking to make MSVC 
2015 the minimum.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to not fix: Building with gcc-4.6 for Fx38+

[bowen]

On Wednesday, March 11, 2015 at 5:14:39 PM UTC, Ehsan Akhgari wrote:
> On 2015-03-11 8:34 AM, bo...@mozilla.com wrote:
> > Given that we (and probably Chromium) would be unlikely to drop MSVC 2013 
> > before our next ESR anyway
> 
> That is not true.  The compiler that we use to build ESR has nothing to 
> do with the minimum compiler requirements on mozilla-central.

I wasn't suggesting that they are tied in some way.
I was just suggesting that there is a good chance that we won't have dropped 
MSVC 2013 by next March.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to not fix: Building with gcc-4.6 for Fx38+

[bowen]

On Tuesday, March 10, 2015 at 2:38:43 PM UTC, Ehsan Akhgari wrote:
> Have you tested bumping the gcc min version here 
> 
>  
> to see if there are any builders that still use gcc 4.6?

I haven't, no.
I assume you mean by pushing to try.
Here's a push in case the bugs don't exist in certain builds:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=044e896fc6fa

Thanks.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to not fix: Building with gcc-4.6 for Fx38+

[bowen]

I have now updated the two MDN pages (that I know of) to reflect that gcc-4.7 
or later is now required.




This has made the following C++11 features available for use in Mozilla code:

* member initializers
* template aliases
* delegated constructors
* override and final as C++ keywords

Cheers,
Bob
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

PSA: New C++11 features made available by dropping support for gcc-4.6 in Gecko 38

[bowen]

I was asked to repost this in a new thread in case it got lost ...

I have now updated the two MDN pages (that I know of) to reflect that gcc-4.7 
or later is now required.




This has made the following C++11 features available for use in Mozilla code:

* member initializers
* template aliases
* delegated constructors
* override and final as C++ keywords

Cheers,
Bob 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Please help with testing a low integrity level for the content process sandbox on Windows.

[bowen]

I have just landed a patch which changes the "level 1" Windows content process 
sandbox policy to one which runs the process at a low integrity level from the 
start. This will hopefully make it into tomorrow's Nightly.
(pref: security.sandbox.content.level=1)

Running at low integrity for the whole lifetime of the process wasn't possible 
before a recent bug fix.
It turned out that doing this (instead of dropping to low integrity later in 
the process) seemed to fix the major blocker to using low integrity.

Low is the same integrity level at which Internet Explorer's Protected Mode 
sandbox runs.

I would be grateful if anyone testing e10s on Windows, would also take some 
time to test with this stronger sandbox policy.
Just set the above pref and then restart Firefox, so that the new policy is 
applied to the content process.

If you find any issues caused by this, please file them to block bug 1151767.

You can turn on limited sandbox logging to the browser console with the pref:
security.sandbox.windows.log

This doesn't log all the things that the sandbox might block, but it should log 
things that we might be able to fix by adding new policy rules.
You can filter the output with "Process Sandbox".
Please copy (or attach) anything that looks like it might be relevant into the 
bug.

You can also get a stack trace in the log entry with:
security.sandbox.windows.log.stackTraceDepth

The logging requires a restart, but changing the stack trace depth should not.

I hope to change this policy to the default one later this month.

Thanks,
Bob
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Windows content process sandbox now low integrity by default

[bowen]

Following on from my previous post [1], I have now landed a patch that makes 
the Windows content process sandbox low integrity by default.
(pref: security.sandbox.content.level=1)

I know of only one regression that this causes at the moment. 
This is that printing using the "Microsoft XPS Document Writer" or selecting 
"Print to file" fails (Bug 1156742).

Due to this problem, this is a Nightly only change at the moment and will not 
currently move to Aurora when e10s does.

If you need this feature, you could temporarily open a non-e10s window and 
print from there.
If you use it a lot, then you can go back to the previous default (pref: 
security.sandbox.content.level=0), which requires a restart.

For any other issues caused by this, please file them to block bug 1151767.
I know this is stating the obvious :-), but you can test that they are caused 
by this change by retrying with the previous level 0 default as mentioned above.

(Repeated from my previous post)
You can turn on limited sandbox logging to the browser console with the pref:
security.sandbox.windows.log

This doesn't log all the things that the sandbox might block, but it should log 
things that we might be able to fix by adding new policy rules.
You can filter the output with "Process Sandbox".
Please copy (or attach) anything that looks like it might be relevant into the 
bug.

You can also get a stack trace in the log entry with:
security.sandbox.windows.log.stackTraceDepth

The logging requires a restart, but changing the stack trace depth should not.

Thanks,
Bob

[1] https://groups.google.com/forum/#!topic/mozilla.dev.platform/QaSdtSMGM7c
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Is there an e10s plan for multiple content processes?

[bowen]

On Wednesday, 6 May 2015 02:26:17 UTC+1, Mike Hommey  wrote:
 
> Nuwa, aiui, can somewhat help here, but the possibly best option is
> actually to just not have a separate executable and fork() the main
> process (I didn't say this was going to be easy)

Not having a separate executable has some other advantages for the Windows 
Chromium sandbox as well.
Both Chrome and the Flash Player Plugin use the same executable for the 
sandboxed processes.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Process-level mitiagtions are being turned on for the Windows content process sandbox

[bowen]

Hi all,

The next Nightly should have certain process-level mitigations turned on for 
the Windows content process sandbox.

These are Chromium sandbox features that ensure that things like DEP, ASLR and 
SEHOP are turned on for the content process when available.

If you are running Nightly on Windows with e10s enabled, this will be on by 
default.

Please file any regressions this causes to block bug 119.

You can test by:
* using a weaker sandbox by setting security.sandbox.content.level to 0 and 
restarting
* turning off the content sandbox altogether by setting an environment variable 
MOZ_DISABLE_CONTENT_SANDBOX to 1 before starting Firefox.

Thanks,
Bob
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Please help test the low integrity NPAPI plugin sandbox for Flash on Windows

[bowen]

Hi all,

At the end of last week I landed patches that allow us to add running at low 
integrity to our potential sandbox policy for NPAPI processes on Windows.

I would be grateful if anyone who uses Nightly on Windows would test the Flash 
plugin running with our sandbox.

You can do this by setting the following pref:
dom.ipc.plugins.sandbox-level.flash=2

If the flash NPAPI process is already running, you'll need to restart for this 
to take affect.

I'm particularly interested in testing on 64-bit Firefox, but 32-bit will be 
useful as well.

On 32-bit, setting this pref will automatically turn off Flash's own protected 
mode.

Please file any issues you find to block bug 1123759.

Thanks,
Bob

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: searchfox now indexing Windows Rust/C++ code

[bowen]

On Friday, 2 November 2018 15:32:37 UTC, Kartikaya Gupta  wrote:
> Hello searchfox fans,
> 
> Those of you working in Windows-only Rust and C++ code will probably
> be happy to hear that as of today searchfox is indexing the
> Windows-only bits of our codebase as well.

This will make such a difference, thank you!
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Please help to test remote Canvas 2D on Nightly

[bowen]

Hi all,

On Windows, as part of our work to move GPU access and win32k system calls out 
of the content process, we are moving accelerated Canvas 2D to the GPU process.

I am nearly ready to enable this by default on Nightly and would really 
appreciate it if people running Nightly on Windows would do some initial 
testing to shake out any serious problems first.

In order to help, firstly update to the latest Nightly, to make sure you have 
some fixes that have just landed.
Then, to enable remote 2D canvas, in about:config set gfx.canvas.remote=true 
and restart Firefox.

Please file any problems you find as bugs blocking:
https://bugzilla.mozilla.org/show_bug.cgi?id=1547286

Thanks,
Bob
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

PSA: Remote Canvas 2D is being enabled on Nightly

[bowen]

Hi all,

I have just landed the patch to enable moving accelerated Canvas 2D to the GPU 
process on Windows.

This is only enabled on Nightly at the moment and is part of our work to move 
GPU access and win32k system calls out of the content process.

Please file any problems you find as bugs blocking:
https://bugzilla.mozilla.org/show_bug.cgi?id=1548487

Thanks,
Bob
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: Remote Canvas 2D is being enabled on Nightly

[bowen]

Well that was short lived ... although not totally unexpectedly.

This has been disabled again for the moment, while I investigate regressions.
Two of these I think are too frequent for us to carry in Nightly.

Both of these frequent ones look like they are things that are normally 
non-fatal issues when they happen in the content process, but I need to find 
the scenarios and catch them in the recording code and not when they are played 
back in the GPU process.

Apologies for any issues this may have caused you, but if you have good steps 
to reproduce for any of these GPU crashes, please file them to block:
https://bugzilla.mozilla.org/show_bug.cgi?id=1547286

You can still set gfx.canvas.remote to true to test this.

Thanks,
Bob

On Wednesday, 20 November 2019 16:36:49 UTC, bo...@mozilla.com  wrote:
> Hi all,
> 
> I have just landed the patch to enable moving accelerated Canvas 2D to the 
> GPU process on Windows.
> 
> This is only enabled on Nightly at the moment and is part of our work to move 
> GPU access and win32k system calls out of the content process.
> 
> Please file any problems you find as bugs blocking:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1548487
> 
> Thanks,
> Bob

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Remote Canvas 2D has been re-enabled on Nightly

[bowen]

Hi all,

The latest Nightly has the pref re-enabled to move accelerated Canvas 2D to the 
GPU process on Windows.

This is only enabled on Nightly at the moment and is part of our work to move 
GPU access and win32k system calls out of the content process.

Please file any problems you find as bugs blocking:
https://bugzilla.mozilla.org/show_bug.cgi?id=1548487

Thanks,
Bob
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform