On Wed, 24 Jul 2024 14:32:51 +, Raymond Hackley wrote:
> Touch keys feature on fortuna phones are provided by Zinitix touchscreen.
> Add property linux,keycodes to enable touch keys.
>
>
Applied, thanks!
[1/1] arm64: dts: qcom: msm8916-samsung-fortuna: Add touch keys
On 24.07.2024 4:32 PM, Raymond Hackley wrote:
> Touch keys feature on fortuna phones are provided by Zinitix touchscreen.
> Add property linux,keycodes to enable touch keys.
>
> Signed-off-by: Raymond Hackley
> ---
please bump the revision (v1 -> v2) when changing the commit
Touch keys feature on fortuna phones are provided by Zinitix touchscreen.
Add property linux,keycodes to enable touch keys.
Signed-off-by: Raymond Hackley
---
arch/arm64/boot/dts/qcom/msm8916-samsung-fortuna-common.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts
> See the "In case your patch fixes a bug.." paragraph in:
>
> https://docs.kernel.org/process/submitting-patches.html
Hi Konrad,
the point is not to fix a bug, but to add touchkeys support instead.
I will reword the patch when it's confusing.
Regards,
Raymond
On 23.07.2024 3:39 PM, Raymond Hackley wrote:
>> Fixes?
>>
>> Konrad
>
> Hi Konrad,
>
> the issue is not reported or discussed on lkml, so there is no thread to fix?
See the "In case your patch fixes a bug.." paragraph in:
https://docs.kernel.org/process/submitting-patches.html
>
> Regards,
>
> Fixes?
>
> Konrad
Hi Konrad,
the issue is not reported or discussed on lkml, so there is no thread to fix?
Regards,
Raymond
On 23.07.2024 3:12 PM, Raymond Hackley wrote:
> The phone needs the touchkeys to be enabled so the sense lines of the
> touch controller are mapped properly. Otherwise the touchscreen is not
> mapped to the display properly.
>
> Signed-off-by: Raymond Hackley
> ---
Fixes?
Konrad
The phone needs the touchkeys to be enabled so the sense lines of the
touch controller are mapped properly. Otherwise the touchscreen is not
mapped to the display properly.
Signed-off-by: Raymond Hackley
---
arch/arm64/boot/dts/qcom/msm8916-samsung-fortuna-common.dtsi | 2 ++
1 file changed, 2
On Tue, Apr 19, 2005 at 04:31:47AM +, David Wagner wrote:
> Theodore Ts'o wrote:
> >For one, /dev/urandom and /dev/random don't use the same pool
> >(anymore). They used to, a long time ago, but certainly as of the
> >writing of the paper this was no longer true. This invalidates the
> >enti
Theodore Ts'o <[EMAIL PROTECTED]> writes:
> With a properly set up set of init scripts, /dev/random is
> initialized with seed material for all but the initial boot
What about CD-ROM based distros (e.g., Knoppix), where every boot is
the initial boot?
> (and even that problem can be solved by ha
Theodore Ts'o wrote:
>For one, /dev/urandom and /dev/random don't use the same pool
>(anymore). They used to, a long time ago, but certainly as of the
>writing of the paper this was no longer true. This invalidates the
>entire last paragraph of Section 5.3.
Ok, you're right, this is a serious f
On Mon, Apr 18, 2005 at 09:40:37PM +, David Wagner wrote:
> Yes, that is a minor glitch, but I believe all their points remain
> valid nonetheless. My advice is to apply the appropriate s/MD5/SHA1/g
> substitution, and re-read the paper to see what you can get out of it.
>
> The problem is no
Matt Mackall wrote:
>On Sat, Apr 16, 2005 at 01:08:47AM +, David Wagner wrote:
>> http://eprint.iacr.org/2005/029
>
>Unfortunately, this paper's analysis of /dev/random is so shallow that
>they don't even know what hash it's using. Almost all of section 5.3
>is wrong (and was when I read it in
[please reply to all when posting to lkml]
On Sat, Apr 16, 2005 at 01:08:47AM +, David Wagner wrote:
> >First, a reminder that the design goal of /dev/random proper is
> >information-theoretic security. That is, it should be secure against
> >an attacker with infinite computational power.
>
forgot to state the assumption. Some people reviewing the design
>>don't notice the omission.
> Ok, now I understand your objection. Yup, this is a real objection.
> You are right to ask questions about whether this is a reasonable assumption.
>
> I don't know whethe
Jean-Luc Cooke wrote:
>The part which suggests choosing an irreducible poly and a value "a" in the
>preprocessing stage ... last I checked the value for a and the poly need to
>be secret. How do you generate poly and a, Catch-22? Perhaps I'm missing
>something and someone can point it out.
I do
linux wrote:
>Thank you for pointing out the paper; Appendix A is particularly
>interesting. And the [BST03] reference looks *really* nice! I haven't
>finished it yet, but based on what I've read so far, I'd like to
>*strongly* recommnd that any would-be /dev/random hackers read it
>carefully. I
+1. This seems to me an extremely plausible example.
>
> Consider a Fortuna-like thing with two pools. The first pool is seeded
> with n, then the second with n+b0, then the first again with n+b0+b1.
> n is the arbitrary starting count, while b0 and b1 are independent
>
linux wrote:
>David Wagner wrote:
>>linux wrote:
>>> First, a reminder that the design goal of /dev/random proper is
>>> information-theoretic security. That is, it should be secure against
>>> an attacker with infinite computational power.
>
>> I am skeptical.
>> I have never seen any convincing
On Sat, Apr 16, 2005 at 05:16:22PM -, [EMAIL PROTECTED] wrote:
> > "How does the entropy estimator measure entropy of the event?" becomes a
> > crucial concern here. What if, by your leading example, there is 1/2 bit
> > of entropy in each event? Will the estimator even account for 1/2 bits?
On Sat, Apr 16, 2005 at 10:05:55AM -, [EMAIL PROTECTED] wrote:
> MErging e-mails, first from [EMAIL PROTECTED]:
> > You really ought to look at the _current_ implementation. There is no
> > SHA1 code in random.c.
>
> So I'm imagining the call to sha_transform() in 2.6.12-rc2's
> extract_buf()
stimate and crypto
> primitives don't fail to leak information, then we're OK"
Er.. "if the crypto primitives don't fail TO leak information"?
I'm not quite sure I follow...
>> 2) Fortuna tries to support such a wide range of entropy source rates,
&
> Correct me if I'm wrong here, but uniformity of the linear function isn't
> sufficent even if we implemented like this (right now it's more a+X than
> a X).
>
> The part which suggests choosing an irreducible poly and a value "a" in the
> preprocessing stage ... last I checked the value for a an
s it easier to improve. You're 100% correct - security
wise it doesn't matter.
> 1) Fortuna is trying to sidestep the hard problem of entropy measurement,
>to make it unnecessary. This is a laudable goal, but /dev/random's
>information-theoretic design goal prec
On Sat, Apr 16, 2005 at 11:10:33AM -, [EMAIL PROTECTED] wrote:
> Thank you for pointing out the paper; Appendix A is particularly
> interesting. And the [BST03] reference looks *really* nice! I haven't
> finished it yet, but based on what I've read so far, I'd like to
> *strongly* recommnd th
>> /dev/urandom depends on the strength of the crypto primitives.
>> /dev/random does not. All it needs is a good uniform hash.
>
> That's not at all clear. I'll go farther: I think it is unlikely
> to be true.
>
> If you want to think about cryptographic primitives being arbitrarily
> broken,
>> First, a reminder that the design goal of /dev/random proper is
>> information-theoretic security. That is, it should be secure against
>> an attacker with infinite computational power.
> I am skeptical.
> I have never seen any convincing evidence for this claim,
> and I suspect that there are
tion for the time being.
Great, we agree! (Okay, almost.) My point about "the neat name" was a
facetious straw-man. That's a metaphor for "some stupid non-technical
reason". Newer is not neceaarily better. But your reason for liking
Fortuna is not quite that sha
linux wrote:
>/dev/urandom depends on the strength of the crypto primitives.
>/dev/random does not. All it needs is a good uniform hash.
That's not at all clear. I'll go farther: I think it is unlikely
to be true.
If you want to think about cryptographic primitives being arbitrarily
broken, I t
ked in a way that affects /dev/random than that
SHA1 will be broken in a way that affects /dev/random.
>In addition, Fortuna is profligate with entropy, [...]
Yup.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL P
Jean-Luc Cooke wrote:
>Info-theoretic randomness is a strong desire of some/many users, [..]
I don't know. Most of the time that I've seen users say they want
information-theoretic randomness, I've gotten the impression that those
users didn't really understand what information-theoretic randomn
>First, a reminder that the design goal of /dev/random proper is
>information-theoretic security. That is, it should be secure against
>an attacker with infinite computational power.
I am skeptical.
I have never seen any convincing evidence for this claim,
and I suspect that there are cases in wh
Matt Mackall wrote:
>While it may have some good properties, it lacks
>some that random.c has, particularly robustness in the face of failure
>of crypto primitives.
It's probably not a big deal, because I'm not worried about the
failure of standard crypto primitives, but--
Do you know of any ana
On Fri, Apr 15, 2005 at 12:22:25PM -0400, Jean-Luc Cooke wrote:
> And the argument that "random.c doesn't rely on the strength of crypto
> primitives" is kinda lame, though I see where you're coming from. random.c's
> entropy mixing and output depends on the (endian incorrect) SHA-1
> implementati
On Fri, Apr 15, 2005 at 03:38:01PM -, [EMAIL PROTECTED] wrote:
>
> First of all, people *on* the netowrk path can just *see* the packets.
> Or modify them. Or whatever.
> The point is to prevent hijacking by people *not* on the path.
Yes, you're correct of course. Of course, I'll note that
hen I was reading random.c for the first time. First
impressions and all.
> As for hacking Fortuna in, could you give a clear statement of what
> you're trying to achieve?
>
> Do you like:
> - The neat name,
> - The strong ciphers used in the pools, or
> - The multi-pool r
or the endianness of the SHA-1, are you trying to imply
something? Because it makes zero difference, and reduces the code
size and execution time. Which is obviously a Good Thing.)
As for hacking Fortuna in, could you give a clear statement of what
you're trying to achieve?
Do you like:
- The
ck entropy for some
> > time.
>
> It depends on how often you reseed, but my recollection was that it
> was far more than years; it was *centuries*. And as far as I'm
> concerned, that's equivalent to throwing it away, especially given the
> pathetically small size of t
but
>> it hoards some for years, thereby making it effectively unavailable.
>> Any catastrophic reseeding solution has to hold back entropy for some
>> time.
> It depends on how often you reseed, but my recollection was that it
> was far more than years; it was *centuries*.
c reseeding solution has to hold back entropy for some
> time.
It depends on how often you reseed, but my recollection was that it
was far more than years; it was *centuries*. And as far as I'm
concerned, that's equivalent to throwing it away, especia
o fame is that it tries to achieve that
without explicitly measuring entropy.
> My big concern with Fortuna is that it really is the result of
> cryptographic masturbation. It fundamentally assumes that crypto
> primitives are secure (when the recent break of MD4, MD5, and now SHA1
> I'll not make any claim that random-fortuna.c should be mv'd to random.c, the
> patch given allows people to kernel config it in under the Cryptographic
> Options menu. Perhaps a disclaimer in the help menu would be in order to
> inform users that Fortuna has profound conseque
the post-state.
Actually, if you check the current random.c code, you'll see that it
has catastrophic reseeding in its design already.
> So Fortuna would be helped by some better understanding of what exactly
> makes it fail, so the discussion could move to whether real-world
> seed sour
enu. Perhaps a disclaimer in the help menu would be in order to
inform users that Fortuna has profound consequences for those expecting
Info-theoretic /dev/random?
The case where an attacker has some small amount of unknown in the pool is a
problem that effects BOTH random-fortuna.c and random.c
Just to refersh everyone's memory as to the strengths and weaknesses
of Fortuna...
First, a reminder that the design goal of /dev/random proper is
information-theoretic security. That is, it should be secure against
an attacker with infinite computational power. If you want a weaker
guar
; > > Any insight on how to test syn cookies and the other network stuff in
> > > random.c? My patch is attached, but I havn't tested that part yet.
> >
> > For starters, this is not against anything like a current random.c. A
> > great number of cleanups h
.c? My patch is attached, but I havn't tested that part yet.
>
> For starters, this is not against anything like a current random.c. A
> great number of cleanups have been done.
You caught me. :)
Last I proposed Fortuna for /dev/random it nearly got me drawn and quarterd.
So I'
On Wed, Apr 13, 2005 at 07:43:37PM -0400, Jean-Luc Cooke wrote:
> Ahh. Thanks Herbert.
>
> Matt,
>
> Any insight on how to test syn cookies and the other network stuff in
> random.c? My patch is attached, but I havn't tested that part yet.
For starters, this is not against anything like a curr
FIPS140
> post processor before handing you a random number it would be nice to
> take advantage of that IMO.
For those who are interested, my Fortuna patch to the Linux RNG (/dev/random,
/dev/urandom) is available here (2.6.12-rc1, works on kernels as low as
2.6.11.4):
http://jlcooke.ca
49 matches
Mail list logo
