User: Password:
|
|
Subscribe / Log in / New account

Recently posted comments

the higher road

Posted Jul 25, 2017 23:16 UTC (Tue) by sfeam (subscriber, #2841)
In reply to: Credits and payments by corbet
Parent article: Faster reference-count overflow protection

Don't let the bastards wear you down. The LWN kernel coverage benefits your subscribers and the larger community of readers. Publication of incessant sniping by PaXTeam does not. The better choice is to continue the former and block the latter. There is no shame in choosing to killfile sources of predictable aggrevation. I know there is always a temptation to peek at messages in the spam bin, but resist it.


Credits and payments

Posted Jul 25, 2017 22:55 UTC (Tue) by andresfreund (subscriber, #69562)
In reply to: Credits and payments by corbet
Parent article: Faster reference-count overflow protection

> The point is coming where I'm just not going to write about this work anymore, it's simply not worth the shitstorm that results every time. There is a lot of other kernel work going on — work that your patch sets depend on — that I can write about without wishing I'd chosen a different line of work.

That'd be sad - at least I appreciate them. And from my POV it seems that minimizing mainline security work is pretty much PaXTeam's goal. Reducing positive-ish coverage of such efforts seems like part of that.

If necessary I'd rather see you disable comments on these articles, or just you putting PaXTeam on ignore.


Credits and payments

Posted Jul 25, 2017 22:40 UTC (Tue) by corbet (editor, #1)
In reply to: Faster reference-count overflow protection by PaXTeam
Parent article: Faster reference-count overflow protection

So, PaX...is $OTHER_PUBLICATION paying you nicely for repeatedly trashing our writing? :)

The patch set is described as coming from Kees Cook, based on work in PaX/grsecurity. That is objectively true. More to the point, that patch set contains a great deal of work to separate out the changes, make them acceptable to mainline, document them, run benchmarks, etc. All part of the normal work required to get a change upstream. You have, as is your right, declined to do that work. But when somebody else does it for you, the result is their work as much as yours.

I write pretty routinely about patch sets here. They often contain work from multiple people, often in ways that is hard to tell. If I were to credit everybody who somehow influenced a patch set, the articles would be long indeed. The current patch set originated in your work — which was noted in the article — but also contains contributions from Kees, Josh Poimboeuf, Ingo Molnar, Li Kun, and probably others, most of whom were not credited in the article. But only you, who were actually credited, chose to publicly question my integrity (again).

The point is coming where I'm just not going to write about this work anymore, it's simply not worth the shitstorm that results every time. There is a lot of other kernel work going on — work that your patch sets depend on — that I can write about without wishing I'd chosen a different line of work.


Faster reference-count overflow protection

Posted Jul 25, 2017 21:47 UTC (Tue) by renox (subscriber, #23785)
In reply to: Faster reference-count overflow protection by PaXTeam
Parent article: Faster reference-count overflow protection

Well you can speak for me: given the lack of precision of the source of the improvement in the article, I thought that kees was the creator of the improvement.

And this is not the first time that I'm disturbed by this kind of imprecision in lwn..


The end of Flash

Posted Jul 25, 2017 21:28 UTC (Tue) by josh (subscriber, #17465)
In reply to: The end of Flash by lkundrak
Parent article: The end of Flash

QWOP has an HTML5 version these days.

So does zombocom, and so do several other interesting historical Flash animations.


The end of Flash

Posted Jul 25, 2017 21:26 UTC (Tue) by fratti (subscriber, #105722)
In reply to: The end of Flash by zlynx
Parent article: The end of Flash

Now rinse and repeat for all the other awful parts of "the web", which is steadily growing. Battery level monitoring? Check. WebMIDI? Check.

Not to forget JS could create canvas elements at will, so you really need to intercept it at some other level than the DOM, unless you want to slow down every page that ever touches the DOM in any way.


The end of Flash

Posted Jul 25, 2017 21:23 UTC (Tue) by zlynx (subscriber, #2285)
In reply to: The end of Flash by fratti
Parent article: The end of Flash

Except that it's trivial in Firefox and Chrome extensions to search the DOM for canvas elements and do whatever you want to them. Much easier than Flash which is either enabled to do anything or disabled.


The end of Flash

Posted Jul 25, 2017 21:06 UTC (Tue) by lkundrak (subscriber, #43452)
In reply to: The end of Flash by nix
Parent article: The end of Flash

> Quite. Some fairly major cultural artifacts

QWOP! Which probably is the most major cultural artifact made in this century!


The end of Flash

Posted Jul 25, 2017 20:56 UTC (Tue) by fratti (subscriber, #105722)
In reply to: The end of Flash by josh
Parent article: The end of Flash

WebGL and canvas, which unlike Flash can't be made click-to-play as easily but is thus widely used for hardware fingerprinting.

And let's not forget WebUSB, which for some reason is a thing.

And while we're at it, WebRTC leaking IPs from behind a VPN isn't nice either.


The end of Flash

Posted Jul 25, 2017 20:36 UTC (Tue) by nix (subscriber, #2304)
In reply to: The end of Flash by donbarry
Parent article: The end of Flash

Quite. Some fairly major cultural artifacts (Homestuck, anyone)? are Flash-based in whole or part: it's horrible for almost everything, but there are a few things it worked well for. Just destroying those artifacts by throwing the program away without opening it is appalling.


The end of Flash

Posted Jul 25, 2017 20:30 UTC (Tue) by josh (subscriber, #17465)
In reply to: The end of Flash by fratti
Parent article: The end of Flash

With the exception of EME, what new aspect of what browsers have implemented do you have an issue with?


The end of Flash

Posted Jul 25, 2017 20:20 UTC (Tue) by fratti (subscriber, #105722)
Parent article: The end of Flash

I'm not rejoicing, they're killing flash because browsers have implemented all its rich media awfulness. We're now less secure because we can't disable it as easily.


Trust Issues: Exploiting TrustZone TEEs (Project Zero)

Posted Jul 25, 2017 19:50 UTC (Tue) by farnz (subscriber, #17727)
In reply to: Trust Issues: Exploiting TrustZone TEEs (Project Zero) by rvfh
Parent article: Trust Issues: Exploiting TrustZone TEEs (Project Zero)

You can statically lay out memory, so that for each supported framebuffer size, you have a fixed memory layout, including a fixed size pool of buffers for networking. You can do double and triple buffering without an OS backing you (it's just buffer swapping in an interrupt handler at heart).

I've worked on MPEG-2 decoders that did exactly that - triple buffered display at any of the standard resolutions for HD-SDI, ASI reception with a buffer pool for inbound packets, hardware decoder that needed software to depacketise in the right format, all managed by a linker script in a single bare-metal application. Even supported picture-in-picture and both Teletext font-based and DVB bitmap subtitles.


Trust Issues: Exploiting TrustZone TEEs (Project Zero)

Posted Jul 25, 2017 19:34 UTC (Tue) by wahern (subscriber, #37304)
In reply to: Trust Issues: Exploiting TrustZone TEEs (Project Zero) by roc
Parent article: Trust Issues: Exploiting TrustZone TEEs (Project Zero)

The ARM TrustZone isn't immune to side-channel attacks, either, AFAIU. Certainly not in an absolute sense, as timing attacks have been demonstrated across ethernet. You still need to write your software carefully, taking into account the myriad ways in which an attacker can poke and prod your code, locally or remotely.

I think it's just been less of an issue on ARM because until recently 1) most ARM chips were single core, or at least TrustZone code was often pinned to a single core, and 2) people weren't doing pre-emptive scheduling in the TrustZone. In that case it was easier to ensure sensitive cryptographic operations ran to completion consistently. But that's rapidly changing, because reasons (performance, etc). In x86 land I think we'll soon see the ability for user processes to reliably detect context switches. That way you can flush the cache, cryptographically sign some data, and flush again, without being interrupted. (I don't know if that's sufficient alone, just that it should be more feasible to implement the requisite measures.)


The end of Flash

Posted Jul 25, 2017 18:53 UTC (Tue) by donbarry (guest, #10485)
Parent article: The end of Flash

Adobe created this proprietary problem, and Adobe is not being a good citizen in ending it.

Why do I say this?

Because the appropriate solution isn't to simply disappear the proprietary flash plugin, but rather open it and release it as free software.

I am not saying that to encourage its continued use and am happy to see it die for new material. Rather, freeing flash is primarily necessary to help data archivists a decade or a century from now who will have no good way to understand content archived now for whatever cultural or scientific studies may wish a look at our age, of which significant content, for better or worse, is on flash and will not be migrated.

A generation of net users became caught by the "flash trap", and it will be a pity to have a black hole in the archives of our culture because of the past predaceousness and continued contempt of one company.


The end of Flash

Posted Jul 25, 2017 18:29 UTC (Tue) by josh (subscriber, #17465)
Parent article: The end of Flash

And there was much rejoicing!

I still remember this being one of the most noticeable issues, when I first switched to Linux and stuck entirely with FOSS from Debian main.

That got *much* easier when scripts like youtube-dl (and its various predecessors) came around, and still easier when major sites started switching to HTML.

These days, sites actually using Flash without any HTML alternative have become vanishingly rare, and simply choosing to ignore them and move on doesn't cause any significant problems for me.


Trust Issues: Exploiting TrustZone TEEs (Project Zero)

Posted Jul 25, 2017 17:37 UTC (Tue) by Wol (guest, #4433)
In reply to: Trust Issues: Exploiting TrustZone TEEs (Project Zero) by rvfh
Parent article: Trust Issues: Exploiting TrustZone TEEs (Project Zero)

What do you mean by memory management? Things like malloc etc?

They're not required for an OS. Yes, using static memory means you have to think a lot harder about what you're doing, and the programmer has to actively manage it, rather than let the computer sort it out at run time, but I used to work with an OS written in FORTRAN ...

Cheers,
Wol


Faster reference-count overflow protection

Posted Jul 25, 2017 17:09 UTC (Tue) by PaXTeam (guest, #24616)
In reply to: Faster reference-count overflow protection by nix
Parent article: Faster reference-count overflow protection

can't speak for you but i'm fine with the truth ;). now you tell me who you think authored this fast 'single instruction overhead' refcount mechanism when you read "With his fast refcount overflow protection patch set, Kees Cook would indeed appear to have found that solution."


Faster reference-count overflow protection

Posted Jul 25, 2017 16:56 UTC (Tue) by tlamp (subscriber, #108540)
In reply to: Faster reference-count overflow protection by tao
Parent article: Faster reference-count overflow protection

Make the security enhancement opt out through kconfig then and we're done.

Those who really need every cycle can disable it then and sane distros can ship their kernel with them, maybe ship even two versions.


Faster reference-count overflow protection

Posted Jul 25, 2017 16:31 UTC (Tue) by quotemstr (subscriber, #45331)
In reply to: Faster reference-count overflow protection by ianmcc
Parent article: Faster reference-count overflow protection

Yet here we are. We have to deal with human nature as it is, not as we'd like it to be.



Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds