Quoting: pete910

Quoting: LeonardK

Quoting: pete910

Quoting: LeonardKoh, there we go, I thought I was fast enough debunking the tinfoil but apparently I wasn't. The paper was done by the same researchers who already "targeted" Intel multiple times and the researchers never claimed AMD CPUs being exploitable either. However, they're research found that the L1d predictor is vulnerable, which can prove useful in future research.

I agree but reverse engineering a component then simulating it without knowing that it's correct then missing rest of the CPU/firmware safe guards is misleading.

It's a totally valid approach. We have to remember that this is a *research paper*, not someone claiming "they hacked AMD". They pick one component and anlyse it, they don't "misleadingly leave out". In the paper itself, they also explicitly state the model and attack vector. But one can also guess at how irrelevant the paper is to *systems administrators* by it not being pushed by the researches, there's no big website as with meltdown/spectre/lvi etc.

I understand it's a valid approach, Their method of analysis is fine on a academic level, In practice it's very flawed due to obvious reasons.

Trouble is it has been mislead as an actual vulnerability/possible exploit when it's not by various media outlets/headlines.

Sure the coverage was misleading (as almost always in IT-sec), I'm only arguing against the science being flawed or the researches being paid by Intel.

View this comment - View article - View full comments

Quoting: pete910

Quoting: LeonardKoh, there we go, I thought I was fast enough debunking the tinfoil but apparently I wasn't. The paper was done by the same researchers who already "targeted" Intel multiple times and the researchers never claimed AMD CPUs being exploitable either. However, they're research found that the L1d predictor is vulnerable, which can prove useful in future research.

I agree but reverse engineering a component then simulating it without knowing that it's correct then missing rest of the CPU/firmware safe guards is misleading.

It's a totally valid approach. We have to remember that this is a *research paper*, not someone claiming "they hacked AMD". They pick one component and anlyse it, they don't "misleadingly leave out". In the paper itself, they also explicitly state the model and attack vector. But one can also guess at how irrelevant the paper is to *systems administrators* by it not being pushed by the researches, there's no big website as with meltdown/spectre/lvi etc.

View this comment - View article - View full comments

Quoting: pete910It's PR stunt paid by Intel again.

They isolated the L1 design and simulated an attack ignoring the rest of the CPUs design/safe guards.

So whilst possible when simulated but so is me drilling through a 6" thick steel plate with my finger under simulation given the right coding :wink:

oh, there we go, I thought I was fast enough debunking the tinfoil but apparently I wasn't. The paper was done by the same researchers who already "targeted" Intel multiple times and the researchers never claimed AMD CPUs being exploitable either. However, they're research found that the L1d predictor is vulnerable, which can prove useful in future research.

View this comment - View article - View full comments

Quoting: NanobangOk, there's a security issue, but what is the security issue exactly, please? I see they both involve "shared memory," but that's about all I can really understand from the paragraph, and since I don't know what that is, I don't really understand anything.

Is this something I need to be concerned about, really? Or is this one of those security exploits requiring, like, someone has physical access to the computer, is logged in as root, and has a valid driver's license in 3 countries or some such?

I've not read the paper, but the vulnerability is in the predictor of the L1d cache

I don't know how much about caches you know, but basically it's that a subset of the data in the memory is loaded into a super-fast memory on the CPU. The L1d is the first-level (smallest, fastest) data-cache. I suppose the vulnerability aims to make applications leak data to another application via the cache, ie. read another applications data not from memory (which the kernel prevents) but somehow from the cache via speculative loads.

It is a new vulnerability insofar, as this has not been done or researched before. However for this to be exploitable, speculative execution needs to be exploitable, which isn't if the system is fixed -- at least, that's the current state of the art. And that's the important takeaway: Although exploiting might currently need disabling fixes first, maybe someone else will find a way to use this vulnerability w/o disabling the fixes.

View this comment - View article - View full comments

And the tinfoil is already heavily heating up over at r/AMD, people found out that two of the PhD students there have been funded by Intel. They totally miss though, that these researchers have already found some Intel vulns like Meltdown etc., also being funded by Intel.

It's getting worse because this vulnerability is only presenting a new attack vector on one component but not a complete exploit for patched hardware. Again, people ignore how research works: You focus on *one* critical component, because doing otherwise would mean never being actually done. Although this vulnerability is not exploitable, it adds a puzzle piece to the toolbox that might prove useful if the current Speculation-attack countermeasures fail or someone finds a completely different way to use this vector. Or someone might be inspired by this *completely new approach* to find an exploit that works without disabling aforementioned countermeasures. This is research, not a security review (and, well, being someone who does security reviews, we do also mention unexploitable vulnerabilities because you never know...).

View this comment - View article - View full comments

Ah, maybe they're then ready to also deploy my Linux port of the original game, at least as a steam beta, too. Last time they were too busy with other projects to look at my code here
https://steamcommunity.com/app/255320/discussions/0/558749191480300587/?ctp=3#c2572002906842087140 [External Link]
https://gitlab.com/LeonardKoenig/EH-TB_Linux/ [External Link]

View this comment - View article - View full comments

Weird, I have no issues at all using the Vulkan Renderer. Runs flawlessly on high settings. It's not perfectly fast but definitely playable on good settings.

View this comment - View article - View full comments

Quoting: qptain Nemo

Quoting: LeonardKIt's damn slow, had more crashes since I installed it than any other program and annoys the hell out of me with its shitty user interface. eh.
/rant :)

Could you elaborate about the things you dislike about the user interface? I don't wish to argue about appeal of discord, I think we've made our cases, but I'm somewhat enthusiastic about UI design and I'm always curious to know what works and what doesn't for other people.

Most importantly it doesn't "fit in" into my environment, doesn't adhere to my themes etc. and completely sticks out.

Also the user interface is mouse-focused or touch, it works with the keyboard but it's far from what I'd want, because I cannot customize the keyboard interface to the amount I'd want. It's also far from responsive, and clutters the UI with unneeded animations or similar bells 'n' whistles

The interface tries to "tell you" what you should click, if you get my point. But I know what *I* want and it annoys the hell out of me.

And finally, something that's not UI but UX related: I have to use the discord-program to use the discord-protocol.

View this comment - View article - View full comments

Quoting: qptain NemoYou did a good thing!

Thanks!

Because it's currently the best application for IM and group chat and voice chat. The only real competitor (I'm talking primarily feature-wise) during the rise of Discord was Matrix and Discord was significantly faster at adding features and capturing the mainstream audience. It's not the most perfect application for those purposes theoretically possible but I stand by that it's simply the best available as well as the best I've ever used.

I honestly don't really see the appeal for this, the most common use-case for discord group chats doesn't seem to be serious chatting anyway but spamming memes :p

So irc or even telegram groups are far superior imho there. And voice chat is usually done by a completely different group, so a different program would do, and those usually do that better. Also I have a big distaste for what a friend called "rainbow-puking javascript shit". It's damn slow, had more crashes since I installed it than any other program and annoys the hell out of me with its shitty user interface. eh.

/rant :)

View this comment - View article - View full comments

Quoting: LeonardKThey're really supportive there and maybe now they have time to look into my patches for their first Edna and Harvey installment to maks it run on Linux natively (they told me they had something "big" to release first) :p

They will release a remastered version of the first Edna in 2019 that will support Linux. They've announced that on their official discord.[/quote]Cool! Meanwhile I made this: https://gitlab.com/LeonardKoenig/EH-TB_Linux [External Link]

And why does everyone use discord nowadays :-(

View this comment - View article - View full comments