Re: [9fans] Spectre and Meltdown

Re: [9fans] Spectre and Meltdown

[cinap_lenrek]

wait and see if all these scrambled together mitigations actually work.

9front is not in the business of selling shared computing environments
(or sell executable javascript ads) to untrusted strangers.

that was never really safe to begin with. there will be bugs in software
and hardware. and there will be side channels.

if you are concerned about security and leaks then run your authentication
server on a dedicated box and applications on your own terminal.

--
cinap

Re: [9fans] Spectre and Meltdown

[Skip Tavakkolian]

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

good advice. i agree with the wait-and-see. i'm not convinced that this
issue is solvable.

using pip, npm and all the other ways of importing random code from
who-knows-where is insanity and plan9 systems (mostly?) avoid this practice.
having dedicated auth and fs servers (don't allow cpu'ing) and using
terminals for each user is a good practice.
a terminal on an affected processor can still compromise your factotum data
in memory. rpi3 is a safe choice and, for plan9, probably the best choice.



On Wed, Jan 10, 2018 at 8:59 AM, <cinap_lenrek@felloff.net> wrote:

> wait and see if all these scrambled together mitigations actually work.
>
> 9front is not in the business of selling shared computing environments
> (or sell executable javascript ads) to untrusted strangers.
>
> that was never really safe to begin with. there will be bugs in software
> and hardware. and there will be side channels.
>
> if you are concerned about security and leaks then run your authentication
> server on a dedicated box and applications on your own terminal.
>
> --
> cinap
>
>

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

Re: [9fans] Spectre and Meltdown

[Erik Quanstrom]

[-- Attachment #1: Type: text/html, Size: 1877 bytes --]

Re: [9fans] Spectre and Meltdown

[Skip Tavakkolian]

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

i think "javascript in the browser" is implied here. and that is a HUGE
gate to close.

fortunately, we don't have such browsers in plan9 :)

On Wed, Jan 10, 2018 at 11:41 AM, Erik Quanstrom <quanstro@quanstro.net>
wrote:

> to be fair, this vulnerability can be exploited with plain old JavaScript.
>
> On Jan 10, 2018 11:32, Skip Tavakkolian <skip.tavakkolian@gmail.com>
> wrote:
>
> good advice. i agree with the wait-and-see. i'm not convinced that this
> issue is solvable.
>
> using pip, npm and all the other ways of importing random code from
> who-knows-where is insanity and plan9 systems (mostly?) avoid this practice.
> having dedicated auth and fs servers (don't allow cpu'ing) and using
> terminals for each user is a good practice.
> a terminal on an affected processor can still compromise your factotum
> data in memory. rpi3 is a safe choice and, for plan9, probably the best
> choice.
>
>
>
> On Wed, Jan 10, 2018 at 8:59 AM, <cinap_lenrek@felloff.net> wrote:
>
> wait and see if all these scrambled together mitigations actually work.
>
> 9front is not in the business of selling shared computing environments
> (or sell executable javascript ads) to untrusted strangers.
>
> that was never really safe to begin with. there will be bugs in software
> and hardware. and there will be side channels.
>
> if you are concerned about security and leaks then run your authentication
> server on a dedicated box and applications on your own terminal.
>
> --
> cinap
>
>
>
>

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

Re: [9fans] Spectre and Meltdown

[Erik Quanstrom]

[-- Attachment #1: Type: text/html, Size: 2746 bytes --]

Re: [9fans] Spectre and Meltdown

[Skip Tavakkolian]

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

yep. i mentioned npm, but there are a few more.

On Wed, Jan 10, 2018 at 12:56 PM, Erik Quanstrom <quanstro@quanstro.net>
wrote:

> it is also exploitable in node.js.
>
> On Jan 10, 2018 12:52, Skip Tavakkolian <skip.tavakkolian@gmail.com>
> wrote:
>
> i think "javascript in the browser" is implied here. and that is a HUGE
> gate to close.
>
> fortunately, we don't have such browsers in plan9 :)
>
> On Wed, Jan 10, 2018 at 11:41 AM, Erik Quanstrom <quanstro@quanstro.net>
> wrote:
>
> to be fair, this vulnerability can be exploited with plain old JavaScript.
>
> On Jan 10, 2018 11:32, Skip Tavakkolian <skip.tavakkolian@gmail.com>
> wrote:
>
> good advice. i agree with the wait-and-see. i'm not convinced that this
> issue is solvable.
>
> using pip, npm and all the other ways of importing random code from
> who-knows-where is insanity and plan9 systems (mostly?) avoid this practice.
> having dedicated auth and fs servers (don't allow cpu'ing) and using
> terminals for each user is a good practice.
> a terminal on an affected processor can still compromise your factotum
> data in memory. rpi3 is a safe choice and, for plan9, probably the best
> choice.
>
>
>
> On Wed, Jan 10, 2018 at 8:59 AM, <cinap_lenrek@felloff.net> wrote:
>
> wait and see if all these scrambled together mitigations actually work.
>
> 9front is not in the business of selling shared computing environments
> (or sell executable javascript ads) to untrusted strangers.
>
> that was never really safe to begin with. there will be bugs in software
> and hardware. and there will be side channels.
>
> if you are concerned about security and leaks then run your authentication
> server on a dedicated box and applications on your own terminal.
>
> --
> cinap
>
>
>
>
>
>

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

Re: [9fans] Spectre and Meltdown

[Richard Miller]

> rpi3 is a safe choice

Safe against spectre perhaps, but there are interesting remote attacks
against the firmware in the bcm43xx wifi engine.  I wouldn't want to bet
on plan 9's immunity to some variant of broadpwn.

Re: [9fans] Spectre and Meltdown

[Bakul Shah]

On Wed, 10 Jan 2018 23:46:47 +0000 Richard Miller <9fans@hamnavoe.com> wrote:
Richard Miller writes:
> > rpi3 is a safe choice
>
> Safe against spectre perhaps, but there are interesting remote attacks
> against the firmware in the bcm43xx wifi engine.  I wouldn't want to bet
> on plan 9's immunity to some variant of broadpwn.

CVE-2017-9417.  Poking around the 'net I found

https://github.com/raspberrypi/linux/issues/1342#issuecomment-321221748

Need Linux to run this but does not fix the problem?

Though there seems to be another unrelated problem that seems
not quite fixed.

Re: [9fans] broadpwn (was Spectre and Meltdown)

[Richard Miller]

> https://github.com/raspberrypi/linux/issues/1342#issuecomment-321221748
>
> Need Linux to run this but does not fix the problem?

No need for linux. If you don't mind installing firmware from random files
on drive.google.com, you can grab the tarball referenced from the url above,
unpack it, and copy brcmfmac43430-sdio.^(bin txt) into /sys/lib/firmware
on your pi3 or pi0w.

You will need to pad the .bin file to a multiple of 2048 bytes (eg by
appending from /dev/zero) otherwise the verify after loading seems to fail.
If you use the piwifi kernel (rootfs from wifi) as opposed to the pi3 kernel
(rootfs from ethernet or sdcard with access to wifi), you'll want to rebuild
the kernel in order to get the updated files into the /boot builtin fs.

There should be a more definitive source for the firmware files somewhere.

> Though there seems to be another unrelated problem that seems
> not quite fixed.

The other two fixes mentioned in that issue (turning off power management
and harcoding packet priority to zero) were already in the plan 9 driver.

Re: [9fans] Spectre and Meltdown

[Skip Tavakkolian]

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

yes; i had forgotten about that.  fortunately there's the ethernet port.

https://www.blackhat.com/docs/us-17/thursday/us-17-Artenstein-Broadpwn-Remotely-Compromising-Android-And-iOS-Via-A-Bug-In-Broadcoms-Wifi-Chipsets.pdf



On Wed, Jan 10, 2018 at 3:46 PM, Richard Miller <9fans@hamnavoe.com> wrote:

> > rpi3 is a safe choice
>
> Safe against spectre perhaps, but there are interesting remote attacks
> against the firmware in the bcm43xx wifi engine.  I wouldn't want to bet
> on plan 9's immunity to some variant of broadpwn.
>
>
>

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

Re: [9fans] Spectre and Meltdown

[hiro]

when did you implement wifi on the rpi?!

Re: [9fans] Spectre and Meltdown

[Rui Carmo]

If that’s working with WPA2, I’m interested too.

> On 11 Jan 2018, at 09:35, hiro <23hiro@gmail.com> wrote:
> 
> when did you implement wifi on the rpi?!
> 

Re: [9fans] Spectre and Meltdown

[Richard Miller]

> when did you implement wifi on the rpi?!

Late 2016.  And yes, it works with wpa2 (thanks to cinap's aux/wpa).

Re: [9fans] Spectre and Meltdown

[hiro]

Cool, so we now have a lot of wifi support in total. never imagined that.

There's prism(Lucent WaveLAN), Ralink RT2860, Ralink RT3090, a bunch
of intels, AND that rpi.

IIUC only the wavelan stuff has hardmac, so no wifi.c -> no wpa2 there.

[9fans] Spectre and Meltdown

[Jules Merit]

23hiro now has dead 46 planberries, no see front
c h ke

On Fri, Jan 12, 2018 at 3:45 AM, hiro <23hiro at gmail.com> wrote:
> Cool, so we now have a lot of wifi support in total. never imagined that.
>
> There's prism(Lucent WaveLAN), Ralink RT2860, Ralink RT3090, a bunch
> of intels, AND that rpi.
>
> IIUC only the wavelan stuff has hardmac, so no wifi.c -> no wpa2 there.
>

[9fans] Spectre and Meltdown

[Jules Merit]

srv ieee-754 trouble, GDS-II stream

On Mon, Jan 15, 2018 at 4:51 PM, Jules Merit
<jules.merit.eurocorp.us at gmail.com> wrote:
> 23hiro now has dead 46 planberries, no see front
> c h ke
>
> On Fri, Jan 12, 2018 at 3:45 AM, hiro <23hiro at gmail.com> wrote:
>> Cool, so we now have a lot of wifi support in total. never imagined that.
>>
>> There's prism(Lucent WaveLAN), Ralink RT2860, Ralink RT3090, a bunch
>> of intels, AND that rpi.
>>
>> IIUC only the wavelan stuff has hardmac, so no wifi.c -> no wpa2 there.
>>

[9fans] Spectre and Meltdown

[Giacomo Tesio]

2018-01-10 17:59 GMT+01:00  <cinap_lenrek at felloff.net>:
> wait and see if all these scrambled together mitigations actually work.

Sorry if this is a dumb question, but the descriptions I read of the
mitigations taken in Linux for Meltdown (in particular kernel
page-table isolation) sound really familiar to my poor understanding
of how plan 9 and 9front already manage user memory.

As far as I can remember plan9 flush tables very often and clearly
separate kernel memory pages and user space memory.


So my dumb question is: are plan9/9front and friends actually
vulnerable to Meltdown?


Giacomo