[erlang-questions] inet:getstat on non-socket crashes the VM?

[Bekes, Andras G]

Hi Erlangers,

 

I noticed that calling inet:getstat/1 is a dangerous operation, as it can kill the whole VM if used inappropriately.

 

It is easy to reproduce:

 

Eshell V9.3  (abort with ^G)

1> application:start(sasl).

ok

2> [inet:getstat(X) || X<-erlang:ports()].

Failed to write to erl_child_setup: 9

Crash dump is being written to: erl_crash.dump...done

 

Without sasl, it doesn’t kill the VM, but the terminal gets into a faulty state and further work is not possible.

I know calling it on a non-socket is an erroneous action, but crashing the VM doesn’t seem to be the most appropriate consequence.

What do you think?

 

Regards,

 

Andras G. Bekes, Vice President   
Morgan Stanley | Institutional Securities Tech   
Lechner Odon Fasor 6 | Floor 06   
Budapest, 1095   
Phone: +36 1 882-0791   
Andras...@morganstanley.com   
   

---

NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions or views contained herein are not intended to be, and do not constitute, advice within the meaning of Section 975 of the Dodd-Frank Wall Street Reform and Consumer Protection Act. If you have received this communication in error, please destroy all electronic and paper copies and notify the sender immediately. Mistransmission is not intended to waive confidentiality or privilege. Morgan Stanley reserves the right, to the extent required and/or permitted under applicable law, to monitor electronic communications, including telephone calls with Morgan Stanley personnel. This message is subject to the Morgan Stanley General Disclaimers available at the following link: http://www.morganstanley.com/disclaimers.  If you cannot access the links, please notify us by reply message and we will send the contents to you. By communicating with Morgan Stanley you acknowledge that you have read, understand and consent, (where applicable), to the foregoing and the Morgan Stanley General Disclaimers.

[Rickard Green]

> _______________________________________________
> erlang-questions mailing list
> erlang-q...@erlang.org
> http://erlang.org/mailman/listinfo/erlang-questions
>

Broadcasting random stuff around is dangerous. Different ports (and processes) have different protocols that they expect to be used. A message that means something for one port may mean something completely different for another port.

Regards,
Rickard
--
Rickard Green, Erlang/OTP, Ericsson AB

[Attila Rajmund Nohl]

2018-06-22 13:53 GMT+02:00 Bekes, Andras G <Andras...@morganstanley.com>:
> Hi Erlangers,
>
>
>
> I noticed that calling inet:getstat/1 is a dangerous operation, as it can
> kill the whole VM if used inappropriately.
>
>
>
> It is easy to reproduce:
>
>
>
> Eshell V9.3 (abort with ^G)
>
> 1> application:start(sasl).
>
> ok
>
> 2> [inet:getstat(X) || X<-erlang:ports()].
>
> Failed to write to erl_child_setup: 9
>
> Crash dump is being written to: erl_crash.dump...done
>
>
>
> Without sasl, it doesn’t kill the VM, but the terminal gets into a faulty
> state and further work is not possible.
>
> I know calling it on a non-socket is an erroneous action, but crashing the
> VM doesn’t seem to be the most appropriate consequence.
>
> What do you think?

I raised a ticket about a similar issue a couple of months ago on
bugs.erlang.org, but got similar answer as you. I cannot link the
ticket number as all I get on bugs.erlang.org is this:

type Exception report

message Unable to establish a connection with the database.
(Connection refused. Check that the hostname and port are correct and
that the postmaster is accepting TCP/IP connections.)

description The server encountered an internal error that prevented it
from fulfilling this request.

exception

com.opensymphony.module.propertyset.PropertyImplementationException:
Unable to establish a connection with the database. (Connection
refused. Check that the hostname and port are correct and that the
postmaster is accepting TCP/IP connections.)

[Per Hedeland]

On 2018-06-25 02:42, Rickard Green wrote:

>
>
> On Fri, Jun 22, 2018 at 1:53 PM, Bekes, Andras G <Andras...@morganstanley.com <mailto:Andras...@morganstanley.com>> wrote:
> >
> > Hi Erlangers,
> >
> >
> >
> > I noticed that calling inet:getstat/1 is a dangerous operation, as it can kill the whole VM if used inappropriately.
> >
> >
> >
> > It is easy to reproduce:
> >
> >
> >
> > Eshell V9.3 (abort with ^G)
> >
> > 1> application:start(sasl).
> >
> > ok
> >
> > 2> [inet:getstat(X) || X<-erlang:ports()].
> >
> > Failed to write to erl_child_setup: 9
> >
> > Crash dump is being written to: erl_crash.dump...done
> >
> >
> >
> > Without sasl, it doesn t kill the VM, but the terminal gets into a faulty state and further work is not possible.
> >
> > I know calling it on a non-socket is an erroneous action, but crashing the VM doesn t seem to be the most appropriate consequence.
> >
> > What do you think?
> >
> >
> >
> > Regards,
> >
> >
> >
> > Andras G. Bekes, Vice President
> > Morgan Stanley | Institutional Securities Tech
> > Lechner Odon Fasor 6 | Floor 06
> > Budapest, 1095
> > Phone: +36 1 882-0791

> > Andras...@morganstanley.com <mailto:Andras...@morganstanley.com>

> >
> >
> >
> > ________________________________
> > NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions or views contained herein are not intended to be, and do not constitute, advice within the meaning of Section 975 of the
> Dodd-Frank Wall Street Reform and Consumer Protection Act. If you have received this communication in error, please destroy all electronic and paper copies and notify the sender immediately.
> Mistransmission is not intended to waive confidentiality or privilege. Morgan Stanley reserves the right, to the extent required and/or permitted under applicable law, to monitor electronic
> communications, including telephone calls with Morgan Stanley personnel. This message is subject to the Morgan Stanley General Disclaimers available at the following link:
> http://www.morganstanley.com/disclaimers. If you cannot access the links, please notify us by reply message and we will send the contents to you. By communicating with Morgan Stanley you acknowledge
> that you have read, understand and consent, (where applicable), to the foregoing and the Morgan Stanley General Disclaimers.
> >
> >
> > _______________________________________________
> > erlang-questions mailing list

> > erlang-q...@erlang.org <mailto:erlang-q...@erlang.org>

> > http://erlang.org/mailman/listinfo/erlang-questions
> >
>
> Broadcasting random stuff around is dangerous. Different ports (and processes) have different protocols that they expect to be used. A message that means something for one port may mean something
> completely different for another port.

Agreed in principle - inet:getstat/1 and many other socket operations
(I forget which one we ran into this problem with) end up calling
erlang:port_control/3, where the 'Operation' argument is indeed an
arbitrary integer with semantics that are specific to the driver / port
program referenced by the 'Port' argument - BUT:

a) Programming errors do happen, and IMHO intentionally terminating the
VM as a means of error handling (which is what the "forker" driver does
in this case) is really not acceptable for a system with all the
sophisticated error handling and expected robustness of Erlang/OTP, and

b) it's a reasonable expectation that *all* drivers and port programs,
and specifically the drivers and port programs included in the
Erlang/OTP distribution, at least do a basic validation of the
'Operation' argument, and I would even suggest that

c) it would be reasonable for the drivers and port programs included in
the Erlang/OTP distribution to use unique values for the 'Operation'
argument, and even have a documented range of those values, to make it
possible for user-written drivers and port programs to avoid using them.

Anyway, in this particular case, the patch below (for OTP 20.3.6), which
just addresses b) for the "forker" driver, but thereby in most cases
also avoids a), seems like a good idea to me... (AFAIR, prim_inet will
actually turn the 'badarg' into 'einval', but it's still way better than
the driver terminating the VM after failing to use some random and
potentially un-initialized arguments to do what it *thought* was
requested...)

--Per Hedeland

--- a/erts/emulator/sys/unix/sys_drivers.c
+++ b/erts/emulator/sys/unix/sys_drivers.c
@@ -1851,6 +1851,11 @@ static ErlDrvSSizeT forker_control(ErlDrvData e, unsigned int cmd, char *buf,
ErlDrvPort port_num = (ErlDrvPort)e;
int res;

+ /* fail with badarg if wrong port_control call */
+ if (cmd != 'S') {
+ return -1;
+ }
+
driver_enq(port_num, buf, len);
if (driver_sizeq(port_num) > sizeof(*proto)) {
return 0;